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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the II interface between IMS Centralized Services (ICS) UE and Service Centralization 
and Continuity (SCC) Application Server (AS). 

This specification defines a new application layer protocol over II interface, specifies the interaction between the ICS 
UE and the SCC AS including session control procedures and supplementary services control procedures. 

The protocol is intended to be independent of the transport-layer protocol used so it can be applied to a number of 
technologies that need different transport-layer protocols. 

The overall ICS architecture is specified in 3GPP TS 23.292 [2]. 

The procedures for delivery of IMS Service Continuity that do not use the II protocol are specified in the document 

3GPPTS 24.237 [13]. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the IMS centralized services. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPPTR 21.905 [1]. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [2] apply: 

ICSUE 

sec AS 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [7] apply 

Access Transfer 

Service Control Signalling Path 

Session Transfer Identifier (STI) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.292 [5] apply: 

PSIDN 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.229 [12] apply: 

default public user identity 

Stable II Session: An session which is setup by the ICS UE using the CS bearer, and for which service control via the 
II interface is apphcable. 
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3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

ICS IMS Centrahzed Services 

sec AS Service CentraUzation and Continuity Application Server 

STI Session Transfer Identifier 

USSD Unstructured Supplementary Service Data 

4 General description 

4.1 General 

For the current version of the specification the application layer protocol is run over Unstructured Supplementary 
Service Data (USSD) transport as defined in 3GPP TS 24.090 [4], however the application layer protocol is not 
restricted to USSD transport. 

4.2 Structure of the protocol 

4.2.1 Introduction 

The II protocol is a message based point to point protocol. The II protocol messages are transported within a point-to- 
point transport-layer protocol and are exchanged between the ICS UE and SCC AS. 

The II protocol is a transport-independent protocol, i.e. the II session control entities can exchange the II protocol 
messages over any transport-layer protocol that connects the ICS UE and the SCC AS. 

The Ilprotocol's notation maintains a format of two parts, i.e. II message common part and II information elements. 
The II message common part is included in every II message. The II information elements those are included in an II 
message depend on a type of II message being sent. 

4.2.2 Application level protocol 

Overall descriptions with application level protocol are specified as following: 

1) it is used to access IMS services (e.g., IMS session origination); 

2) it is a point to point protocol between the ICS UE and the SCC AS; 

3) its protocol does not support authentication; 

4) it does not support segmentation of messages; 

5) its messages are self-identifying; and 

6) it runs over any point-to-point transport-layer protocol (e.g. USSD). 

4.2.3 Transport-layer protocols 
4.2.3.1 General 

The transport-layer protocol that is used to transfer the II protocol messages is a bi-directional point-to-point 
connection between the ICS UE and the SCC AS. This transport-layer protocol is a symmetric connection, i.e. the 
source-point on the transport-layer protocol that is used to send the II protocol messages is also a destination-point for 
the incoming II protocol messages. 
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An II message shall be contained in one transport protocol message and shall not be segmented across transport 
message protocol data units. The combination of the length of the information elements in an II message shall not 
exceed the length of the transport protocol message payload. 

4.2.3.2 USSD as transport-layer protocol 

The USSD provides a point-to-point transport layer connection between the II protocol entities. USSD is specified in 
3GPP TS 24.090 [4]. When USSD is used for transporting the II protocol, the ICS UE and the SCC AS shall set the 
ussd-DataCodingScheme to "1 101", as defined in 3GPP TS 23.038 [19]. For the purposes of this document, USSD is 
regarded as a real-time reliable transport protocol. 

The USSD supports a two-way alternative interactive communication (i.e. semi-duplex communication). At any given 
time, only one II protocol entity (either the ICS UE or the SCC AS) with its turn may send the II messages, while at the 
same time its peer is permitted only to receive the II messages. To allow the II protocol entity (either the ICS UE or the 
SCC AS) to send an II message to its peer when needed, the initiating entity shall send an II message exchange in a 
single invoke and return result transaction. That is, after the II protocol entities have exchanged II message(s) in a 
USSD invoke component and a USSD return result component, the USSD connection are released. 

When the USSD is used as the transport layer connection, overall descriptions are specified as following: 

1) the initiating entity (either the ICS UE or the SCC AS) shall send a single USSD invoke and the responding 
entity (either the SCC AS or the ICS UE) shall send a return result; 

2) if the responding entity (either the SCC AS or the ICS UE) does not need to send an II response in the return 
result, the responding entity shall send an II -Dummy message to the peer; and 

3) if the II session is established, the USSD connection will be released. 

For mobile initiated requests, the ICS UE shall use the Process Unstructured SS Request invoke component defined in 
3GPP TS 24.090 [4]. The SCC AS shall identify the UE by matching the MSISDN received with the II message with 
the C-MSISDN of the UE. The SCC AS shall send either an II response to the II message or an II Dummy message (if 
no II response is required) in the Process Unstructured SS Request return result. 

NOTE: When forwarding the II message from the UE to the SCC AS, the HSS includes the optional MSISDN 
information element along with the mandatory IMSI information element in the Process Unstructured SS 
Request, as defined in 3GPP TS 23.078 [20]. 

For network initated requests, the SCC AS shall use either the Unstructured SS Request or the Unstructured SS Notify, 
as defined in 3GPP TS 23.078 [20] to send an II message to the HSS for delivery to the UE. When sending the II 
message to the HSS, the SCC AS shall include within the selected invoke component the MSISDN information element 
populated with the C-MSISDN for the UE. When the Unstructured SS Notify invoke component is used, no II message 
is included in the return reply because the Unstructured SS Notify return result does not include any information 
elements. The ICS UE shall include either an II response to the II message or an II Dummy (if no II response is 
required) in the Unstructured SS Request return result. 

The II Dummy in sent in the USSD return result in response to the following II messages in the USSD invoke: II 
Progress, II Success, and II Failure. 



5 Functional entities 

5.1 User Equipment (UE) 

To be compliant with this specification, a UE shall implement the role of ICS UE capabilities defined in 

subclauses 6.2.1.2, 6.2.3.2,6.2.4.2,6.2.5.2.1,6.2.5.3.1, 6.4.3, 7.5.2.1.1, 7.5.2.2.1, 7.5.2.3.1, 7.5.3.2.1.1, and 7.5.3.2. 

2.1. 
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5.2 Application Server (AS) 



To be compliant with this specification, a AS shall implement the role of SCC AS capabilities defined in 

subclauses 6.2.1.3, 6.2.3.3,6.2.4.3,6.2.5.2.2, 

6.2.5.3.2, 6.4.4, 7.5.2.1.2, 7.5.2.2.2, 7.5.2.3.2, 7.5.3.2.1.2, and 7.5.3.2.2.2. 



6 Communication between ICS UE and SCC AS via 11 

interface 

6.1 Introduction 

The ICS UE and SCC AS use the II interface to setup, control, maintain and release an II session control channel and 
associated media over the CS bearer. 

If an ICS US capable of using the II interface registers with the IM CN Subsystem (IMS), it shall associated keys with 
public user identities in the format of a SIP URI in accordance with annex A. A public user identity can be derived if a 
key is associated with the public user identity. 



6.2 Session control procedures 
6.2.1 Session setup 



6.2.1.1 General 

The ICS UE setups the II session with CS media and the service control signalling via the II reference point. II is used 
to control services in the IM CN subsystem. 

The II sessions can be created by II session setup messages. The II Invite message is an II session setup message. The 
II sessions can be torn down by II session release messages. The II Bye message is an II session release message. 

The following subclauses describe the procedures of the ICS UE and the SCC AS for II session setup: 

subclause 6.2.1.2.1 describes the procedures of ICS UE II session origination; 

subclause 6.2. 1 .2.2 describes the procedures of ICS UE II session termination without UE assisted T-ADS 
function; 

subclause 6.2.1.2.3 describes the procedures of ICS UE II session termination with UE assisted T-ADS function; 

subclause 6.2. 1 .2.4 describes the procedures of ICS UE when the II session fails; 

subclause 6.2. 1.3.1 describes the procedures of SCC AS II session origination; 

subclause 6.2.1.3.2 describes the procedures of SCC AS II session termination without UE assisted T-ADS 
function; 

subclause 6.2.1.3.3 describes the procedures of SCC AS Ilsession termination with UE assisted T-ADS function; 
and 

subclause 6.2.1.3.4 describes the procedures of SCC AS when the II session fails. 
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6.2.1 .2 Detailed behaviour of ICS UE 

6.2.1 .2.1 ICS UE CS Session Origination 

6.2.1.2.1.1 General 

The following subclauses describe the procedures at the ICS UE for session origination. 

6.2.1.2.1.2 Sending an II Invite message 

When the ICS UE originates an II session using the protocol at the Ilreference point, the UE shall: 

1) generate an II Invite message that includes: 

a) a Message Type and a Reason set to indicate the message is a Mobile Originated II Invite message, 
accordance with table 7.3.1; 

b) a new value in the Call-Identifier field (Part-1), as specified in subclause 7.2.2.1.4. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 

c) an allocated Sequence-ID; 

d) a From-id information element that 

if the UE has previously SIP registered and the public user identity is to be a SIP URI and the public user 
identity can be derived (see annex A) then: 

i) if the public identity indicates the default public user identity, the Code specific field of the From-id 
information element is set to "Unspecified" (see table 7.4.2.3.1-2) and the length field is set to 0; 

ii) if the public identity is not the default public user identity and the public user identity indicated can be 
derived (see annex A), the Code specific field of the From-id information element is set to "Identifier" 
(see table 7.4.2.3.1-2) and the length field is set to 4. 

otherwise the Code specific field of the From-id Information information element is set to: 

i) a "SIP URI" (see table 7.4.2.3.1-2) if the public user identity is a SIP URI and the Information body 
(see table 7.3.2.2) containing the SIP URI; 

ii) an "International number" (see table 7.4.2.3.1-2), if the public user identity is a Tel URI or SIP URI 
with URI parameter user=phone and the Information body (see table 7.3.2.2) containing the digit 
string contained in the URI. 

e) a To-id information element that includes either a SIP URI or an E. 164 number, and will be used by the SCC 
AS to determine the identity of the called user; 

f) a Privacy information element that indicates the ICS UE's privacy preferences. The SCC AS will apply these 
preferences to the SIP session that the SCC AS will establish on behalf of the UE; 

g) optionally include any feature tags in the: 

i) Accept-Contact information element, as specified in subclause 7.3.2.5 if the parameter tag "explicit" or 
"require" as specified in RFC 3841 [14] are not required; 

ii) ERAccept Contact information element, as specified in subclause 7.3.2.6 if the parameter tag "explicit" or 
"require" as specified in RFC 3841 [14] are required; and 

iii) Reject Contact information element as specified in subclause 7.3.2.7; and 

h) if using a transport layer protocol that is not a real-time transport layer protocol, a Timestamp information 
element that includes current local time measured in seconds. The element will be used by the SCC AS to 
determine the staleness of the message. 

2) select the transport-layer protocol (see subclause 4.2.3) depending on the access network type, and forward the 
II Invite message toward the SCC AS. 
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6.2.1 .2.1 .3 Receipt of II Progress message with Reason Call Progress 

When the UE receives an II Progress message with Reason set to 183 (Call Progress), the UE shall: 

1) save the received Call-Identifier field value and use it for further reference to this session; 

2) verify if the message is in sequence according to the value of the Sequence-ID, Timer(s) as specified in 
subclause 7.5.3.2.1 have not expired, and save the received Sequence-ID; 

3) store the SCC AS PSI DN value (i.e. the E.164 number) received in the SCC-AS-id information element; and 

4) store the STI value (i.e. the E.164 number) if received in the Session-identifier information element. 

NOTE 1: The STI value uniquely identifies the II session being established, and it may be subsequently used to 
refer to this II session, e.g. the SCC AS uses the STI to correlate the access transfer request received via 
the PS access with the active session established via the II interface. 

NOTE 2: The UE may indicate the Reason value to the user. 

Upon receiving the SCC AS PSI DN (i.e. the E.164 number) conveyed in the II Progress message with Reason set to 
183 (Call Progress) from the SCC AS, the ICS UE shall initiates the call over the CS domain by sending a CC SETUP 
message to the MSC Server as specified in 3GPP TS 24.008 [3] as follows: 

1) the Called Party BCD Number information element is set to the SCC AS PSI DN (i.e. the E.164 number) 
received in the II Progress message with Reason set to 183 (Call Progress); and 

2) Type Of Number is set to "International" and Numbering Plan Indicator set to "E.164". in the Called Party BCD 
Number information element. 

6.2.1.2.1.4 Receipt of II Progress message with Reason set to 180 
When the ICE UE received an II Progress message with Reason set to 180 the UE shall: 

1) provide an alerting indication to the user; and 

2) verify Timer(s) as specified in subclause 7.5.3.2.1 have not expired. 

6.2.1 .2.1 .5 Receipt of II Success message 
When the ICS UE receives an II Success message, the UE shall: 

1) verify if a II session exists for the received Call-Identifier field value and Timer(s) as specified in 
subclause 7.5.3.2.1 have not expired; 

2) verify if a the message is in sequence according to the value of the Sequence-ID; 

2A) verify that a CC CONNECT message as specified in 3GPP TS 24.008 [3] has been received in response to 
the SETUP message that was sent containing the SCC AS PSI DN; and 

3) consider the II session to be established, if verification was successful. 

6.2.1 .2.2 ICS UE CS Session Termination without UE assisted T-ADS 

If the ICS UE receives an II Invite message from the SCC AS, and the UE determines that no II session exists for the 
received Call-Identifier field value, the ICS UE shall: 

0) if using a transport layer protocol that is not a real-time transport layer protocol, retrieve the SCC AS local time 
value from the Timestamp information element of the II Invite message, and validate the staleness of the 
message by applying the following equation: 

SCC_AS_time_in_the_Il_Invite_message - SCC_AS_time as specified in subclause 6.4.1 item 5) 

>= 

(ICS_UE_local_time - ICS_UE_time as specified in subclause 6.4.3.1 item l)e) - Deviation 
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NOTE: Deviation parameter is 64*T1 seconds. 

If the equation is true the message is not stale and it shall processed by the following sections. Otherwise, the 
messages is discarded and no response is generated to the II Invite message; and 

1) store the information contained in the II Invite message, including the called party identity included in the To-id 
information element, the calling user's public user identity included in the From-id information element, the SCC 
AS PSI DN (i.e., the E.164 number) included in the SCC-AS-id information element, the Sequence-ID, the Call- 
Identifier field (Part-2), the STI value (i.e. the E.164 number) if received in the Session-identifier information 
element, Accept-Contact information element, ERAccept-Contact information element and Reject-Contact 
information element and transport layer information identifying the transport connection over which the II Invite 
message was received; and 

1 A) if the To-id information element in the II Invite message contains a: 

i) Code Specific Information element set to "Unspecified" (see table 7.4.2.3A.1) and a length field set to then 
the Public user identity shall be set to the default public user identity. 

ii) Code Specific Information element set to "Identifier" (see table 7.4. 2. 3A. 1-2) and a length field set to 4, then 
the public user identity can be derived (see Annex A) and shall be set to the identifier value received in the 
information element body of the To-id information element. 

iii) Code Specific Information element set to "International number" (see table 7.4. 2. 3A. 1-2) or "SIP URI" (see 
table 7.4.2.3.1-2), then the public user identity of the UE shall be set to the Identity in the Information 
element body of the To-id information element. 

NOTE 1 : The UE may indicate the public user identity used to address the UE in the incoming session to the user. 

2) initiate a call over CS bearer by sending a CC SETUP message to the MSC Server as specified in 
3GPP TS 24.008 [3] as follows: 

i) the Called Party BCD Number information element is set to the received SCC AS PSI DN (i.e., the E.164 
number) received in the II Invite message 

ii) Type Of Number set to "International" and Numbering Plan Indicator set to "E.164". in the Called Party BCD 
Number information element. 

NOTE 2: When the ICS UE receives an II Invite message, the UE may send an II Progress message with Reason 
set to 180 (Call Progress). The II Progress message with Reason set to 180 (Call Progress) is identical to 
the II Progress message with Reason set to 180 (Ringing) described below, except the Reason field will 
be set to Call Progress. 

When the ICS UE receives an indication from the CS domain that the media resources are available (i.e. the UE 
receives a CC ALERTING message as specified in 3GPP TS 24.008 [3]) and Timer(s) as specified in 
subclause 7.5.3.2.2.1 have not expired, the UE shall: 

1) generate an II Progress message with Reason set to 180 (Ringing) containing the following information: 

a) a Message Type and a Reason set to that indicate the message is an II Progress message, accordance with 
table 7.3.1; 

b) a new value in the Call-Identifier field (Part-1), as specified in subclause 7.2.2. The resulting Call-Identifier 
value uniquely identifies this II session between the UE and SCC AS; 

NOTE 3: A new value in the Call-Identifier field (Part-1) is inserted only if this is the first II message sent to the 
SCC AS. Otherwise the previously set Call-Identifier value is used. 

c) increment the stored message sequence value, store it, and include it in the Sequence-ID; 

d) set the Reason field (per figure 7.3.1) to 180; and 

2) send the II Progress message with Reason set to 180 (Ringing) towards the SCC AS over the transport layer 
connection over which the II Invite message was received. 

If the user accepts the request and Timer(s) as specified in subclause 7.5.3.2.2.1 have not expired, the ICS UE shall: 
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1) generate an II Success message containing the following information: 

a) a Message Type and a Reason set to indicate the message is an II Success message, accordance with 
table 7.3.1; 

b) the stored Call-Identifier value that uniquely identifies this II session between the UE and SCC AS; 

c) increment the stored message sequence value, store it, and include it in the Sequence-ID; and 

2) send the II Success message towards the SCC AS over the transport layer connection over which the II Invite 
message was received. 

6.2.1 .2.3 ICS UE CS Session Termination with UE assisted T-ADS 

If the ICS UE receives an II Invite (Augmentation) message with a Replaces information element and it is determined 
that there is a SIP session being established for the Replaces information element value (e.g., the Replaces information 
element is set to a value identical to (or deduced from) the SIP session identifier in a previously received SIP INVITE), 
the ICS UE: 

1) shall interpret it as session control fallback from Gm to II; and 

2) shall use the Replaces information element value to correlate the II Invite message with the SIP INVITE request 
prevously received, to get SCC AS PSI DN, the called party identity and the calling party identity. 

3) shall indicate that the public user identity, the To-id information element, and the SCC AS PSI DN are in the 
correlated SIP INVITE request, by setting the Code specific field of the To-id information element to 
"Unspecified" (see table 7.4.2.3A.1) and the length field is set to 1 and octet 3 is set to all "0"s, respectively. 

NOTE: In this case, some information element (e.g. Privacy information element) can be omitted from the II 
Invite message, for the information can be obtained by the ICS UE from the correlated SIP INVITE 
request. 

Afterwards, the ICS UE shall behave as specified in subclause 6.2.1.2.2. 

6.2.1.2.4 Failure 

The ICS UE may receive an II Failure message at any time. If the ICS UE receives an II Failure message, the ICS UE 
shall: 

1) save the received Call-Identifier field value and use it for further reference to this session; 

2) verify if the message is in sequence according to the value of the Sequence-ID, and save the received Sequence- 
ID; 

3) extract the Reason Value as defined in subclause 7.2.2.1.3 from the message; and 

4) act in accordance with corresponding equivalent status code value as defined in subclauses 21.3 to 21.6 of 
RFC 3261 [6]. 

5) release the session as defined in subclause 6.2.3 

6.2.1 .3 Detailed behaviour of SCC AS 

6.2.1 .3.1 SCC AS CS Session Origination 

6.2.1.3.1.1 General 

The following subclauses describe the procedures at the SCC AS for II session origination. In this scenario, the SCC 
AS serves the originating user. 

6.2.1.3.1.2 Receipt of 11 Invite message 

Upon receiving an initial II Invite message from the ICS UE via the II reference point, the SCC AS shall: 
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0) if using a transport layer protocol that is not a real-time transport layer protocol, retrieve the ICS UE local time 
value from the Timestamp information element of the II Invite message, and validate the staleness of the 
message by applying the following equation: 

ICS_UE_time_in_the_Il_Invite_message - ICS_UE_time_ as specified in subclause 6.4.4.1 item 1) 

>= 

(SCC_AS_local_time - SCC_AS_time_ as specified in subclause 6.4.4.1 item 3)d) - Deviation 

NOTE: Deviation parameter is 64*T1 seconds. 

If the equation is true the message is not stale and it shall processed by the following sections. Otherwise, the 
messages is discarded and no response is generated to the II Invite message; and 

1) store the information received in the II Invite message, including the called party identity included in the To-id 
information element, From-id information element, the requested privacy type included in the Privacy 
information element, the Sequence-ID, Accept-Contact information element, ERAccept-Contact information 
element and Reject-Contact information element, Call-Identifier field (Part-1) (as specified in 

subclause 7.2.2.1.4), and transport layer information identifying the transport connection over which the II Invite 
message was received; against the IMS private identity of the originating user's UE. The IMS private identity to 
store the information against is determined by comparing the C-MSISDN associated with the IMS private 
identity against the: 

i) MAP service ISDN-Address-String as specificed in 3GPP TS 29.002 [14] if USSD is used as the transport 
layer protocol for the message, 

lA) dynamically allocate a STI and bind it to the information stored in step 1. The STI is specified as an E.164 
number; 

NOTE 1: The STI value uniquely identifies the II session being established, and it may be subsequently used to 
refer to this II session, e.g. the SCC AS uses the STI to correlate the access transfer request received via 
the PS access with the active session established via the II interface. 

IB) If the From-id information element in the II Invite message is 

i) included and the Code Specific information element is set to "Unspecified" (see table 7.4.2.3.1-2) and the 
length field is set to the default public user identity shall be stored against the II Invite message. 

ii) included and the Code Specific information element is set to "Identifier" (see table 7.4.2.3.1-2) and the length 
field is set to 1, the received identifier as derived in Annex A shall be stored against the II Invite message. 

iii) included and the Code Specific information element is set to set to "International number" or "SIP URI" the 
Identity contained in the information element body of the To information element value shall be stored 
against the II Invite message. 

2) Void 

6.2.1 .3.1 .3 Sending an II Progress message in response to II Invite message 

If Timer(s) as specified in subclause 7.5.3.2.1.2 have not expired, the SCC AS shall: 
1) generate an II Progress message containing the following information: 

a) a Message Type and a Reason set to indicate the message is an II Progress message, accordance with 
table 7.3.1; 

b) a Call-Identifier field, that was constructed by appending the allocated Call-Identifier (Part-2) subfield to the 
stored Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2.1.4. The Call-Identifier value uniquely 
identifies this II session between the ICS UE and SCC AS; 

c) add one to the stored message sequence value. Store and include in the Sequence-ID; 

d) include the allocated SCC AS PSI DN (i.e., the E.164 number) in the SCC-AS-id information element; 

e) set the Reason field to 183 (per figure 7.3.1); 
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f) include the allocated STI (i.e., the E.164 number) in the Session-identifier information element; and 

2) send the II Progress message towards the originating ICS UE over the transport layer connection over which the 
II Invite message was received. 

6.2.1 .3.1 .4 Sending an II Progress message with reason set to 180 

If Timer(s) as specified in subclause 7.5.3.2.1.2 have not expired, when sending an II Progress message with Progress 
reason set to 180 towards the originating UE, the SCC AS shall: 

1) generate an II Progress message containing the following information: 

a) the Message Type and a Reason set to indicate the message is an II Progress message, accordance with 
table 7.3.1; 

b) the stored Call-Identifier field (as specified in subclause 7.2.2.1.4) that uniquely identifies this II session 
between the ICS UE and SCC AS ; and 

c) add one to the stored message sequence value. Store and include in the Sequence-ID; and 

2) send the II Progress message towards the originating ICS UE over the transport layer connection over which the 
II Invite message was received. 

6.2.1 .3.1 .5 Sending an II Success message 

If Timer(s) as specified in subclause 7.5.3.2.1.2 have not expired, when sending an II Success message towards the 
orginating ICS UE, the SCC AS shall: 

1) generate an II Success message containing the following information: 

a) a Message Type and a Reason set to indicate the message is an II Success message, accordance with 
table 7.3.1; 

b) a Call -Identifier field containing the Call -Identifier value that uniquely identifies this II session between the 
ICS UE and SCC AS; 

2) add one to the stored message sequence value. Store and include in the Sequence-ID; and 

3) send the II Success message towards the originating ICS UE over the transport layer connection over which the 
II Invite message was received. 

6.2.1 .3.2 SCC AS CS Session Termination without ICS UE assisted T-ADS 

6.2.1.3.2.1 Sending an Initial II Invite message 

When sending an II Invite message towards the ICS UE, the SCC AS shall: 

1) perform the procedures per 3GPP TS 24.292 subclause 10.4.4 item 1; 

lA) dynamically allocate a STI. The STI is specified as an E.164 number; 

NOTE 1: The STI value uniquely identifies the II session being established, and it may be subsequently used to 

refer to this II session, e.g. the SCC AS uses the STI to correlate the access transfer request received via 
the PS access with the active session established via the II interface. 

2) create an II Invite message that includes: 

a) a Message Type and a Reason set to indicate the message is a Mobile Terminated II Invite message, 
accordance with table 7.3.1; 

b) a Call-Identifier field, that includes an allocated Call-Identifier (Part-2) subfield, (see subclause 7.2.2.1.4). 
The Call-Identifier field in spite of containing only the Part-2 value uniquely identifies this II session between 
the ICS UE and SCC AS; 

c) a Sequence-ID; 
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d) a From-id information element that identifies the remote calling party (i.e. obtained from the P-Asserted- 
Identity header field in the SIP INVITE request received from the calling party), if available and if privacy 
was not requested by the calling party as specified in RFC 3323 [8] and RFC 3325 [9]. If either the E.164 
number that identifies the remote calling party is not available or privacy was requested, then the From-id 
information element shall not be included in the II Invite message; 

NOTE 2: The SCC AS will include in the From-id information element the remote calling party only if it is an 
E.164 number and if privacy was not requested. 

e) a To-id information element that; 

- if the UE has previously SIP registered as specified in 3GPP TS 23.218 [17] and the R-URI is a SIP URI 
and the R-URI can be derived (see annex A) then if the R-URI in the received SIP INVITE request is; 

i) the default public user identity as derived in Annex A for the terminating UE then the Code specific 
field of the To-id information element is set to "Unspecified" (see table 7. 4.2. 3A. 1-2) and the length 
field is set to 0. 

ii) is not the default public user identity for terminating UE but matches one of the public user identities 
then the Code specific field of the Identity Information information element is set to "Identifier" (see 
table 7.4.2.3A.1-2) and the length field is set to 1 and the Information Element body of the To-id 
information element information element shall be the identifier value that was derived (see annex A) 
and maps to the Public User Identity that was received in the R-URI in the SIP INVITE request. 

otherwise Code specific field of the To-id information element is set to 

i) a "SIP URI" (see table 7.4.2.3 A. 1-2) if the public user identity is a SIP URI and the Information body 
(see table 7.3.2.2) containing the SIP URI. 

ii) an "International number" (see table 7.4.2.3A.1-2), if the public user identity is a Tel URI or SIP URI 
with URI parameter user=phone and the Information body (see table 7.3.2.2) containing the digit 
string contained in the URI. 

f) a Privacy information element set to the value requested by the remote calling party, if available; 

g) a SCC-AS-id information element that contains an SCC AS PSI DN set to the E.164 number allocated by the 
SCC AS itself as per procedures per 3GPP TS 24.292 subclause 10.4.8 item 2; 

h) a Session-identifier information element that contains the allocated STI; and 

i) if using a transport layer protocol that is not a real-time transport layer protocol, a Timestamp information 
element that includes current local time measured in seconds. The element will be used by the ICS UE to 
determine the staleness of the message. 

3) store the information sent in the II Invite message against the allocated SCC AS PSI DN; and 

4) select the transport layer protocol (see subclause 4.2.3) depending on the access network type, and forward the II 
Invite message toward the ICS UE. 

Subsequently the SCC AS may receive either an II Success message or an II Progress message (with Reason field set 
either to Ringing or Call Progress) from the ICS UE. 

6.2.1 .3.2.2 Receipt of an 11 Progress message 

If Timer(s) as specified in subclause 7.5.3.2.2.2 have not expired, when the SCC AS receives either an II Progress 
message (with Reason field set either to Ringing or Call progressing), the SCC AS shall: 

1) verify if a II session exists for the received Call-Identifier field value; 

2) verify if the message is in sequence according to the Sequence-ID 

3) store the II Progress with reason. 

NOTE 5: The SCC AS will use the information received in the II Progress message (with Reason field set either to 
Ringing or Call Progress) and the information saved in step 2 when handling a SIP session with the remote party. 
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6.2.1 .3.3 sec AS CS Session Termination with ICS UE assisted T-ADS 

The sec AS shall generate an II Invite message to the terminating ICS UE as specified in subclause 6.2.1.3.2.1 with 
the following addition: 

1) Include a Replaces information element in the II (Augmentation) Invite message, which is set to a value 
identical to (or deduced from) the SIP session identifier in the previous SIP INVITE request, to indicate that it is 
session control fallback from Gm to II ; 

2) Indicate that the public user identity, the To-id information element value and the SCC AS PSI DN are in the 
correlated SIP INVITE request, by setting the Code specific field of the To-id information element to 
"Unspecified" (see table 7.4.2.3A.1) and the length field is set to 1 and octet 3 is set to all "0"s. 

NOTE: In this case, some information elements (e.g.. Privacy information element) can be omitted from the II 
Invite message, for the information can be get by the ICS UE from the correlated SIP INVITE request. 

6.2.1.3.4 Failure 
The SCC AS shall: 

1) create an II Failure message that includes: 

a) a Message Type set to the value that indicates that this is an II Failure message; 

b) set the reason value (see table 7.3.1) to the same value as received in the status code as specified in 
subclauses 21.3 to 21.6 of RFC 3261 [6]; 

b) generate a Call-Identifier value that identifies the transaction between the ICS UE and SCC AS. Include the 
Call-Identifier value in the Call-Identifier field in the II Failure message; 

c) generate a Sequence-ID. Include the Sequence-ID in the II Failure Message; 

e) if a contact header value as specified in subclause 21 .3 of RFC 3261 [6] was received in the SIP error 
response include individual To-id information elements containing the URI contents of each contact header 
field. 

f) if reason-phrase header as specified in subclauses 21.3 to 21.6 of RFC 3261 [6] was received, insert the 
contents of the reason-phrase header into the Reason field (see table 7.3.8.1). 

6.2.2 Void 

6.2.3 Session release 

6.2.3.1 General 

II sessions can be torn down by the II session release requests and by receipt of a CC DISCONNECT message as 
specified in 3GPP TS 24.008 [3]. An II Bye message is an II session release request. 

6.2.3.2 Detailed behaviour of ICS UE 

When the ICS UE releases an II session using the II session control channel by sending an II Bye message, it shall: 

1) set the Call-Identifier field to a value that identifies the II session between the ICS UE and SCC AS. Include the 
Call-ID field in the II Bye message; 

2) set the Sequence-ID. Include the Sequence-ID in the II Bye message; 

3) a From-id information element that includes either a SIP URI or an E.164 number, and it will be used by the 
SCC AS to identify the ICS UE; 

4) a To-id information element that includes either a SIP URI or an E. 164 number, and will be used by the SCC AS 
to determine the identity of the called user; 
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5) a Privacy information element that indicates the ICS UE's privacy preferences. The SCC AS will apply these 
preferences to the SIP session that the SCC AS will establish on behalf of the UE; and 

6) if there are no more II service control sessions using the CS bearer, set the CS bearer release timer value. 

If the CS bearer release timer expires, the ICS UE shall send a CC DISCONNECT message to the MSC Server as 
specified in 3GPP TS 24.008 [3], if needed. 

Subsequently, if the ICS UE receives an II Success message from the SCC AS, it shall: 

1) verify if a II session exists for the received Call-Identifier field value; 

2) verify if a the message is in sequence according to the value of the Sequence-ID; and 

3) consider the II session to be released, if verification was successful and clear the CS bearer release timer value. 
When the ICS UE releases a II session using the II session control channel by receiving an II Bye message, it shall: 

1) if there are no more II service control sessions using the CS bearer, the ICS UE shall send a CC DISCONNECT 
message to the MSC Server as specified in 3GPP TS 24.008 [3], if there are no more II service control sessions 
using the CS bearer; 

2) if there are more II service control sessions using the CS bearer, the ICS UE shall transmit a II Success 
message, containing the following information: 

a) a Message Type set to the value that indicates that is an II Success message; 

b) a Call-Identifier field with the stored Call -Identifier value that uniquely identifies this II session between the 
ICS UE and SCC AS; and 

c) increment the stored message sequence value, store it, and include it in the Sequence-ID. 

When the ICS UE receives a CC DISCONNECT message to release the CS bearer as specified in 3GPP TS 24.008 [3]: 

the CS bearer release timer expires shall be cleared, if needed; 

- if the ICS UE has a SIP REGISTER request associated with the ongoing CS call, the UE shall send a SIP 
relNVITE request requesting the media over the CS bearer to be deleted. 

If the ICS UE receives a SIP relNVITE request requesting the media over the CS bearer to be deleted and a 
DISCONNECT message for the CS bearer was already received, the ICS UE shall accept the request to delete the 
media over the CS bearer. 

6.2.3.3 Detailed behaviour of SCC AS 

6.2.3.3.1 Sending an 11 Bye message to the UE 

The SCC AS enhanced for II releases a session by generating and sending an II Bye message, containing the 
information: 

0) a Message Type and a Reason set to indicate the message is an II Bye message, accordance with table 7.3.1; 

1) set the Call -Identifier to a value that identifies the II session between the ICS UE and SCC AS. Include the Call- 
Identifier value in the Call-Identifier field in the II Bye message; 

2) set the Sequence-ID. Include the Sequence-ID in the II Invite message. 

3) include a From-id information element that identifies the remote calling party, if available; 

4) include a To-id information element that includes the E. 164 number of the ICS UE; 

5) include a Privacy information element set to the value requested by the remote calling party, if available; 

6) include a SCC- AS -id information element that contains an SCC AS DN set to the E.164 number allocated by the 
SCC AS itself; and 
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7) store the information sent in the II Bye message against the allocated SCC AS PSI DN. 

6.2.3.3.2 Receipt of 11 Success message from the UE 

If the SCC AS receives an II Success message from the ICS UE, it shall: 

1) verify if a II session exists for the received Call-Identifier field value; 

2) verify if a the message is in sequence according to the value of the Sequence-ID; and 

3) consider the II session to be released, if verification was successful. 

If any of the operations in 1) or 2) fail the II Success message shall be discarded. 

6.2.3.3.3 Receipt of 11 Bye message from the UE 

The SCC AS shall transmit an II Success message using the II session control channel, it shall containing the following 
information: 

a) a Message Type and a Reason set to indicate the message is an II Success message, accordance with 
table 7.3.1; 

b) a Call-Identifier field set to the stored Call-Identifier value that uniquely identifies this II session between the 
ICS UE and SCC AS; and 

c) increment the stored message sequence value, store it, and include it in the Sequence-ID. 

6.2.3A 11 session setup when invoking mid-call supplementary service 
6.2.3A.1 General 

If the ICS UE and SCC AS want to use the II protocol that apply to a CS call that was previously established without 
using the II interfaces (e.g. the call was set as specified in 3GPP TS 24.292 [5] subclause 10.4.7 or subclause 7.4.3), the 
ICS UE and SCC AS may avoid the explicit exchange of the II messages to create an II session to bind it to the 
respective CS call (as specified in subclause 6.2.4). In this case, it is assumed that a reserved Call-Identifier value (i.e. 
all bits set to values "1") will be used to exchange the initial II messages (e.g. mid-call II messages). Hence, the II 
control of an established CS call is acquired (i.e. an II session is automatically created and bound to the respective CS 
call), upon setting up a transport-layer connection between the ICS UE and the SCC AS, and subsequently the ICS UE 
and the SCC AS successfully exchanging the II messages (e.g. the II Mid Call Request message and the II Success 
messages) that use the reserved Call-Identifier value. The ICS UE or SCC AS shall add the II control that uses the that 
a reserved Call-Identifier value to an existing CS call as specified in this subclause only when there is a single CS call 
(i.e. a CS call that was set up without using the II) between the ICS UE and the SCC AS over the CS domain. In this 
case, the information that is already known to the ICS UE and the SCC AS from the existing CS call (e.g. To-id, From- 
id. Privacy) will be also bound to this II session that use the reserved Call-Identifier value and the associated CS call 
(i.e. a CS call that was set up without using the II interfaces). Any II session that is subsequently created shall not use 
the reserved Call-Identifier value. 

The automatically established II session that uses the reserved Call-Identifier value and associated CS call may be to 
control the CS call, e.g. to invoke the mid-call supplementary services or to cleared an CS call that is on hold. 

6.2.3A.2 Detailed behaviour of ICS UE 
6.2.3A.2.1 Mid-call service initiated by ICS UE 

If the ICS UE wants to add the II control to an existing end-to-end CS call that was previously established without 
using the II protocol, and invoke a mid-call supplementary service to this call, the ICS UE shall send an II message to 
the SCC AS. The ICS UE shall populate the II message, as specified in subclause 6.2.1.2.1.2 and subclause 6.3 with the 
following additions: 

1) insert a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2.1.4. When inserting a 
new value in the Call-Identifier (Part-1) subfield, the UE shall set all bits in the Part-1 subfield to values "1" 
(i.e. "11111111"); and 
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NOTE 1: In this case some information is already known to the ISC UE from the existing end-to-end call (e.g. To- 
id, From-id, Privacy) 

2) send the II message to the SCC AS. 

Upon receiving an II Success message from the SCC AS with all bits in the Call-Identifier (Part-1 and Part-2) subfield 
set to values "1", the ICS UE shall treat the II session as established and the requested supplementary service (as 
specified in the subclause 6.3), as applied to the existing end-to-end call (that was set up without using the II protocol). 
The established II session may be subsequently used either by the ICS UE or the SCC AS, to exchange the II messages 
that pertain to this end-to-end call (e.g. send an II Mid Call Request message to resume the call, if the call was 
previously placed on hold, as specified in subclause 6.3). 

NOTE 2: The Call-Identifier (Part-1 and Part-2) subfield with all bits set to values "1" is a reserved value that 
identifies the II session that was automatically created upon invocation of the mid-call supplementary 

service. 

NOTE 3: The allocated STI is always included in the first II message sent by the SCC AS to the ICS UE. If the CS- 
to-PS access transfer is performed prior to the ICS UE obtaining the allocated STI from the SCC AS, the 
static STI is used for the CS-to-PS access transfer, as described in 3GPP TS 24.237 [13]. 

6.2.3A.2.2 Mid-call service initiated by SCC AS 

If the ICS UE receives an II message from the SCC AS that contains the Call-Identifier field with all bits in the Part-2 
subfield set to the values "1", the ICS UE shall identify the call that was previously set without using the II protocol. 

If the ICS UE identifies an existing end-to-end call (that was previously established without using the II protocol), the 
ICS UE shall generate an II Success message containing the information as specified in subclause 6.2.1.2.2 and 
subclause 6.3 with the following additions: 

1) insert a new value in the Call-Identifier (Part-1) subfield with all bits in the Part-1 subfield set to values "1"; and 

2) treat the indicated mid-call supplementary service (specified in subclause 6.3) as applied to the existing call, and 
the II session as established. 

NOTE: The allocated STI is always included in the first II message sent by the SCC AS to the ICS UE. If the CS- 
to-PS access transfer is performed prior to the ICS UE obtaining the allocated STI from the SCC AS, the 
static STI is used for the CS-to-PS access transfer, as described in 3GPP TS 24.237 [13]. 

6.2.3A.3 Detailed behaviour of SCC AS 
6.2.3A.3.1 Mid-call service initiated by ICS UE 

If the SCC AS receives an Ilmessage from the ICS UE that contains the Call-Identifier field with all bits in the Part-1 
subfield set to values "1", the SCC AS shall determine if this II message is for an existing end-to-end call (that was 
previously established without using the II protocol) by using the CS domain number (e.g., MSISDN) obtained from 
the transport layer. If the SCC AS identifies an existing end-to-end call (that was previously established without using 
the II protocol), the SCC AS shall: 

1) perform the steps specified in subclause 6.2.1.3.1.2 and subclause 6.3, and invoke the requested supplementary 
service, as specified in subclause 6.3 (e.g. perform the standard SIP procedures toward the far end and the 
MGCF). 

NOTE 1 : In this case, some information elements that are already known to the SCC AS from the existing CS end- 
to-end call (e.g. To-id, From-id, Privacy) will be bound to the existing (permanent) II session and the 
associated single end-to-end call. 

Upon successfully performing the requested supplementary service, the SCC AS shall generate an II Success message 
containing the information as specified in subclause 6.2.1.3.1.3 and subclause 6.3 with the following additions: 

1) insert a new value in the Call-Identifier (Part-2) subfield, the UE shall set all bits in the Part-2 subfield to values 

2) send the II Success message towards the ICS UE; and 
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3) treat the indicated mid-call supplementary service (specified in subclause 6.3) as applied to the existing end-to- 
end call, and the II session as established. 

NOTE 2: The allocated STI is always included in the first II message sent by the SCC AS to the ICS UE. If the CS- 
to-PS access transfer is performed prior to the ICS UE obtaining the allocated STI from the SCC AS, the 
static STI is used for the CS-to-PS access transfer, as described in 3GPP TS 24.237 [13]. 

6.2.3A.3.2 Mid-call service initiated by SCC AS 

If the SCC AS wants to add the II control to an existing end-to-end call that was previously established without using 
the II protocol, and invoke a mid-call supplementary service to this call, the SCC AS shall: 

1) invoke the supplementary service, as specified in subclause 6.3 (e.g. perform the standard SIP procedures toward 
the far end and the MGCF); and 

2) send an II message to the ICS UE specifying the invoked supplementary service, as specified in subclause 6.3. 
The SCC AS shall populate this II message as specified in subclause 6.2.1.3.2.1 and subclause 6.3 with the 
following additions: 

a) insert a new value in the Call-Identifier (Part-2) subfield, as specified in subclause 7.2.2.1.4. When inserting 
a new value in the Call-Identifier (Part-2) subfield, the UE shall set all bits in the Part-2 subfield to values 
"l";and 

b) not include the SCC-AS-id information element (that includes the SCC AS PSI DN ) in the II message. 

NOTE 1: In this case some information is already known to the SCC AS from the existing end-to-end call (e.g. To- 
id, From-id, Privacy). 

NOTE 2: The allocated STI is always included in the first II message sent by the SCC AS to the ICS UE. If the CS- 
to-PS access transfer is performed prior to the ICS UE obtaining the allocated STI from the SCC ASI, the 
static STI is used for the CS-to-PS access transfer, as described in 3GPP TS 24.237 [13]. 

Upon receiving an II Success message from the ICS UE with all bits in the Call-Identifier (Part-1 and Part-2) subfield 
set to values "1", the SCC AS shall treat the II session as established and the requested supplementary service (as 
specified in the subclause 6.3), as applied to the existing end-to-end call (that was set up without using the II protocol). 
The established II session may be subsequently used either by the ICS UE or the SCC AS, to exchange the II messages 
that pertain to this end-to-end call. 

6.2.4 Adding 11 control to existing CS session (11 Augmentation) 

6.2.4.1 General 

Standard CS procedures can be used to deliver the incoming session to the ICS UE as specified in 3GPP TS 24.292 [5] 
subclause 10.4.7 (SCC AS for call termination over CS to non-ICS UE) or originate a session as specified in 
3GPP TS 24.292 [5] subclause 7.4.3 (ICS UE using CS). Additional IMS parameters or service control can be 
optionally communicated to the ICS UE using II after the call has been setup. The ICS UE or SCC AS shall add II 
control to an existing call only when there is a single session over CS. 

6.2.4.2 Detailed behaviour of ICS UE 
6.2.4.2.1 Augmentation initiated by ICS UE 

If the ICS UE wants to add II control to an existing call that was previously established without using either the II or 
the Gm interfaces, the ICS UE shall send an II Invite message over II interface. The ICS UE shall populate the II Invite 
message as specified in subclause 6.2.1.2.1.2 with the following additions: 

1) set the Reason field in the II Invite message to value hex "002", as specified in Table 7.3.1. This value indicates 
that augmentation is requested; 

NOTE: In this case, some information elements (e.g. From, Privacy) can be omitted from the II Invite message, 
for the information is already known for the ongoing session. 
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Upon receiving an II Success message from the SCC AS, the ICS UE shall treat the ongoing II session as established 
and the existing call being controlled by the respective II session. 

6.2.4.2.2 Augmentation initiated by SCC AS 

If the ICS UE receives a new II Invite message from the SCC AS containing the Reason field set to value hex of "002", 
as specified in Table 7.3.1, the ICS UE shall determine if this II Invite message is for an ongoing call that was 
established without II and Gm. If there is an ongoing call, the ICS UE shall: 

1) respond to the II Invite message with an II Success message; and 

2) treat the ongoing II session as established and the existing call being controlled by the respective II session. 

6.2.4.3 Detailed behaviour of SCC AS 

6.2.4.3.1 Augmentation initiated by ICS UE 

If the SCC AS receives an II Invite message from the ICS UE containing the Reason field set to value hex "002", as 
specified in table 7.3.1, the SCC AS shall determine if this II Invite message is for an ongoing call using the CS 
domain number (e.g., MSISDN)obtained from the transport layer. If there is an ongoing call, the SCC AS shall: 

1) respond to the II Invite message with an II Success message; and 

2) treat the ongoing II session as established and the existing call being controlled by the respective II session. 

6.2.4.3.2 Augmentation initiated by SCC AS 

If the SCC AS wants to add II control to an existing call that was previously established without using either the Gm or 
the II interfaces, the SCC AS shall send a new II Invite message over the II interface. The SCC AS shall populate the 
II Invite message as specified in subclause 6.2.1.3.2.1 with the following addition: 

1) set the Reason field in the II Invite message to value hex of "002", as specified in Table 7.3.1. This value 
indicates that augmentation is requested. 

NOTE: In this case, some information elements (e.g. From-id, To-id, Privacy) can be omitted from the II Invite 
message, for the information is already known for the ongoing session. 

Upon receiving an II Success message, the SCC AS shall treat the ongoing II session as established and the existing 
call being controlled by the respective II session. 

6.2.5 Service control transfer (Gm fallback to 11 ) 
6.2.5.1 General 

When the Gm reference point is used for service control signalling, a change of access network due to handover (e.g. as 
described in 3GPP TS 23.009 [10] and 3GPP TS 25.413 [11]) may result in an inability to use the PS access for the Gm 
reference point. In this case, if the II interface in the target access network is available and supported, the service 
continuity may be maintained by switching the service control signalling from the Gm reference point to the II 
interface. 

If the ICS UE discovers that the Gm reference point is not available for an ongoing session that is using a CS bearer 
which was established over the respective Gm reference point, the ICS UE can transfer the service control signalling 
from the Gm reference point to the II interface, if the II interface is available, while retaining the existing CS bearer 
(i.e. the existing CS bearer is left intact). However, if prior to the change of the access network, the UE was not attached 
to the CS domain and a PS bearer was used for either the voice media or voice and video media of the IMS session, then 
the service continuity may be maintained by switching the service control signalling from the Gm reference point to the 
II interface and transferring the voice media or voice and video media from the PS bearer to the newly-established CS 
bearer. 
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6.2.5.2 Service continuity wliiie retaining the use of CS access for media 

6.2.5.2.1 Detailed behaviour of ICS UE 

When the ICS UE, that has an established IMS session that is using the CS media, originates a service control transfer 
from the Gm reference point to the II reference point while retaining the existing CS bearer and associated media intact, 
the ICS UE shall behavemessage as specified in the subclause 6.2.1.2.1 with the following additions: 

1) include a Replaces information element in the II Invite (Augmentation) message that contains a STI. The STI 
identifies the SIP dialog that was previously established over the Gm reference point on the Source Access Leg 
and will be transferred to this II session on the Target Access Leg. 

2) if the To-id information element is included, and the public user identity inserted in the To-id information 
element is not an E.164 number, then indicate that the public user identity and the To-id information element are 
in the correlated SIP INVITE request, by setting the To-id Information IE (see table 7.3.2.2) Code Specific 
Information element to "Unspecified" (see table 7.4.2. 3A.1) and the length IE is set to 1 and octet 3 is set to all 

"0"s. 

NOTE 1: In this case, some II information elements (e.g. Privacy) can be omitted from the II Invite message, since 
this information is already known to the SCC AS from the ongoing SIP dialog that was previously 
established over the Gm reference point on the Source Access Leg. For example, the inclusion of SIP URI 
into the To-id and From-id information elements is not needed since these information elements may be 
omitted from the II Invite message. 

NOTE 2: It is assumed that when the SIP dialog was established over the Gm reference point, the respective STI 
was used to identify this SIP dialog. 

Upon receiving the II Progress message from the SCC AS, the UE shall not initiates the call setup over the CS domain 
by sending a CC SETUP message to the MSC Server, since the II session will inherit the existing CS media (i.e. the 
existing CS bearer is left intact). 

When the ICS UE receives an II Success message from the SCC AS, the UE shall consider the service control 
signalling as being transferred from the Gm reference point to the Ilinterface and the associated CS media as being 
transferred to the II session (i.e. the II session is now controlling the inherited CS media). Furthermore, the UE shall 
considered the SIP dialog on the Source Access Leg that was originally set using the Gm reference point and all 
remaining PS media associated with this SIP dialog (i.e. the PS media that were not transferred), if any, as terminated. 

NOTE 3: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source 

Access Leg and the II interface over the Target Access Leg, the UE will not receive a SIP BYE request 
from the ICS AS sent over the Gm reference point on the Source Access Leg. 

NOTE 4: Irrespective whether the UE receives a SIP BYE request over Gm reference point on the Source Access 
Leg or not, the UE will consider the SIP dialog on the Source Access Leg and all remaining PS media 
associated with this SIP dialog (i.e. the PS media that were not transferred), if any, as terminated. 

6.2.5.2.2 Detailed behaviour of SCC AS 

If the SCC AS, that supports the II protocol, receives an initial II Invite message with a Replaces information element 
that contains a STI, the SCC AS shall use the STI to identify an existing SIP dialog that was previously established 
using the Gm reference point on the Source Access Leg, and will be replaced with the II session on the Target Access 
Leg. If the identified SIP dialog on the Source Access Leg is currently using a CS bearer, the SCC AS shall behave as 
specified in subclause 6.2.1.3.1 with the following addition: 

1) interpret the received II Invite message containing the Replaces information element as request for service 
control transfer from Gm reference point on the Source Access Leg to the II interface on the Target Access Leg; 

2) correlate the II Invite message with the existing SIP dialog that is using a CS bearer, based on the STI included 
in the Replaces information element; 

NOTE 1: In this case, some information elements (e.g. To-id, From-id, Privacy) may not be included in the II 
Invite message. The omitted II information elements are already known to the SCC AS from the 
ongoing SIP dialog that was previously established over the Gm reference point on the Source Access 
Leg. 
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3) send the II Progress message towards the originating UE that does not include an allocated SCC AS PSI DN; 

NOTE 2: Upon sending the II Progress message towards the originating UE, the SCC AS will not receive an initial 
SIP INVITE request from the CS domain, since the existing CS media will be left intact and only the 
control will be transferred from the SIP dialog identified by the STI in the received Replaces information 
element to the II session being established. 

4) examine whether the SIP dialog on the Source Access Leg has a single CS bearer (i.e. no PS bearers) associated 
with this SIP dialog, or there are additional PS bearers (in addition to the CS bearer) associated with this SIP 
dialog. 

a) if there is a single CS bearer and no PS bearers associated with this SIP dialog, the SCC AS proceeds with 
the steps below, starting with the step 5; or 

NOTE 3: In spite of the service control being transferred from the Gm reference point to the II interface, there is no 
need to update the remote UE by sending a new SDP offer since the CS media has been left intact. 

b) if, in addition to a CS bearer, there are additional PS bearers associated with this SIP dialog, the SCC AS 
shall proceed as follows: 

i) send a SIP re-INVITE request toward the CS domain (e.g. MGCF) that does not contain an SDP offer; 

ii) upon receiving an SDP offer from the CS domain (in the response to the SIP re-INVITE request), the 
SCC AS update the remote UE by sending a SIP re-INVITE request toward the the remote UE. The SDP 
offer included in the SIP re-INVITE request sent toward the the remote UE contains the information 
received in the SDP offer from the CS domain and terminates all the PS bearers, as per standard SIP 
procedures; 

iii) upon receiving the SDP answer in the response to the SIP re-INVITE request from the remote UE, the 
SCC AS sends an SIP ACK toward the CS domain (e.g. MGCF) that contains an SDP anwer. The SDP 
answer contains the information obtained from the SDP answer conveyed in the response to the SIP re- 
INVITE request received from the remote UE. In addition, the SCC AS sends a SIP ACK toward the 
remote UE; 

iv) proceeds with the steps below; 

5) release the SIP dialog on the Source Access Leg by sending a SIP BYE request via the SIP dialog over the Gm 
reference point on the Source Access Leg, if the SIP dialog is still active; and 

NOTE 4: The SIP dialog may have been released by the IMS core network as specified in 3GPP TS 24.229 [12], 
subclause 5.2.8. L2. 

NOTE 5: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source 
Access Leg and the II interface over the Target Access Leg, the SCC AS will not receive a 200 (OK) 
response to a SIP BYE request. 

NOTE 6: Irrespective whether the SCC AS receives a 200 (OK) response to the SIP BYE request over the Gm 
reference point on the Source Access Leg or not, the SCC AS will consider the dialog on the Source 
Access Leg and all remaining PS media associated with this dialog (i.e. the PS media that were not 
transferred), if any, as terminated. 

6) send an II Success message to the UE over the II interface. Upon sending the II Success message to the UE, the 
SCC AS shall consider the service control signalling as being transferred from the Gm reference point to the II 
interface and the associated CS media as being transferred to the II session (i.e. the II protocol is now 
controlling the inherited CS media). 

6.2.5.3 Service continuity when transferring from PS access to CS access 

When an UE, that has an established SIP dialog that is using only the PS media (i.e. no CS media) and the Gm reference 
point for service control signalling (e.g. the UE is not attached to the CS domain), determines that the Gm reference 
point is not anymore available, the UE may maintain service continuity by switching the service control signalling from 
the Gm reference point to the II reference point and an associated PS bearer to the CS bearer. 

The II protocol is used to transfer either a single PS voice media or a single PS voice and PS video media session to a 
single CS bearer. If there are more then one active PS voice media or PS voice media and PS video media associated 
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with the SIP dialog being transferred, then the last-established active PS voice media or PS voice and PS video media 
will be transferred from the PS domain to the CS domain. If there are only inactive PS voice media or PS voice and PS 
video media associated with the SIP dialog, then the last-established inactive PS voice media or PS voice and PS video 
media will be transferred from the PS domain to the CS domain. In either case, the SIP dialog and all associated PS 
media that were not transferred are terminated. 

If the transferred media was active prior to the transfer, it shall stay active upon the completion of the transfer 
procedure. Likewise, if the transferred media was inactive prior to the transfer, it shall stay inactive upon the completion 
of the transfer procedure. 

6.2.5.3.1 Detailed behaviour of UE 

When the UE, that has an established SIP dialog that is using only the PS media (i.e. no CS media), transfers the service 
control signalling from the Gm reference point to the II interface and either the voice media or the voice and video 
media from the PS access to the CS access, the UE behave as specified in subclause 6.2.1.2.1 with the following 
additions: 

1) include a Replaces information element in the II Invite message that contains the STL The STI identifies the SIP 
dialog that was previously established over the Gm reference point on the Source Access Leg and will be 
transferred to the II session on the Target Access Leg. 

NOTE 1: In this case, some II information elements (e.g. To-id, From-id, Privacy) can be omitted from the II 

Invite message, since this information is already known to the SCC AS from the ongoing SIP dialog that 
was previously established over the Gm reference point on the Source Access Leg. For example, the 
inclusion of SIP URI into the To-id and From-id information elements is not needed since these 
information elements may be omitted from the II Invite message. 

NOTE 2: It is assumed that when the SIP dialog was established over the Gm reference point, the respective STI 
was used to identify this SIP dialog. 

When the UE receives an II Progress message from the SCC AS that contains an lUA PSI DN, the UE shall initiates a 
call over the CS domain using the received lUA PSI DN, as specified in subclause 6.2.1.2.1. 

When the UE receives an II Success message from the SCC AS, the UE shall consider the service control signalling as 
being transferred from the Gm reference point to the Ilinterface and the associated voice media or voice and video 
media as been transferred from the PS domain to the CS domain. Furthermore, the UE shall considered the SIP dialog 
on the Source Access Leg that was originally set using the Gm interface and all remaining PS media (i.e. the PS media 
that were not transferred), if any, associated with this SIP dialog as terminated. 

NOTE 3: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source 

Access Leg and the II interface over the Target Access Leg, the UE will not receive a SIP BYE request 
from the SCC AS over the Source Access Leg. 

NOTE 4: Irrespective whether the UE receives a SIP BYE request over the Gm reference on the Source Access Leg 
or not, the UE will consider the dialog on the Source Access Leg and all remaining PS media associated 
with this SIP dialog that were not transferred, if any, as terminated. 

6.2.5.3.2 Detailed behaviour of SCC AS 

If the SCC AS that supports the II protocol receives an initial II Invite message with a Replaces information element 
that contains a STI, the SCC AS shall use the STI to identify an existing SIP dialog that was previously established 
using the Gm reference point on the Source Access Leg and will be replaced with the II session on the Target Access 
Leg. If the identified SIP dialog on the Source Access Leg is currently using only PS media, the SCC AS shall behave 
as specified in subclause 6.2.1.3.1 with the following addition: 

1) interpret the received II Invite message containing the Replaces information element as request for service 
control transfer from Gm reference point on the Source Access Leg to the II interface on the Target Access Leg; 

2) correlate the II Invite message to an existing SIP dialog (and is using only PS bearers), based on the STI 
received in the Replaces information element, and select a PS bearer that is using either a voice media or voice 
and video media and that will be transferred to the CS bearer; 
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NOTE 1 : If there are more then one active PS voice media or PS voice media and video media associated with the 
SIP dialog, the SCC AS selects the last-established active PS voice media or PS voice and video media. If 
there are only inactive PS voice media or PS voice and video media associated with the SIP dialog, then 
the SCC AS selects the last-established inactive PS voice media or PS voice and video media. 

3) send the II Progress message towards the originating UE that includes an allocated SCC AS PSI DN, as 
specified in subclause 6.2.1.3.1; 

Upon receiving the initial SIP INVITE request from the CS domain, the SCC AS shall updates the Remote Leg by 
sending an SIP re-INVITE request toward the remote UE that include an SDP offer. The SDP offer included in the SIP 
re-INVITE request sent toward the the remote UE specifies which media is being transferred to the CS domain, and 
which PS media, if any, are being terminated. When generating the SDP offer towards the remote UE, the SCC AS shall 
use the information received in the SDP offer in the SIP INVITE request received from the CS domain and terminates 
all the PS bearers that have not been transferred to the CS domain, as per standard SIP procedures. 

Upon receiving a SIP 200 (OK) response from the remote UE that contains an SDP answer, the SCC AS shall send the 
SIP 200 (OK) response towards the CS domain that includes a SDP answer. The SDP answer sent towards the CS 
domain contains the media information that pertains to the voice media or voice and video that has been received in the 
SDP answer from the remote UE and is being transferred to the CS domain. 

Upon receving a SIP ACK request from the CS domain, the SCC AS shall send a SIP ACK tovard the remote UE, and: 

release the SIP dialog on the Source Access Leg by sending a SIP BYE request via the SIP dialog over the Gm 
reference point on the Source Access Leg, if the SIP dialog is still active; and 

send an II Success message toward the UE over the II interface. 

NOTE 2: The SIP dialog may have been released by the IMS core network as specified in 3GPP TS 24.229 [12], 
subclause 5.2.8.1.2. 

Upon sending the II Success message to the UE, the SCC AS shall consider the service control signalling as being 
transferred from the Gm interface to the Ilinterface and the associated CS media as being transferred to the II session 
(i.e. the II protocol is now controlling the transferred CS media). 

NOTE 3: If the UE is incapable of simultaneously communicating over the Gm reference point on the Source 
Access Leg and the II interface over the Target Access Leg, the SCC AS will not receive a 200 (OK) 
response to the SIP BYE request from the UE. 

NOTE 4: Irrespective whether the SCC AS receives a 200 (OK) response to the SIP BYE request over the Gm 
reference point on the Source Access Leg or not, the SCC AS will consider the dialog on the Source 
Access Leg and all non-transferred PS media associated with this dialog, if any, as terminated. 

6.2.5.3.3 P-CSCF releasing the source access leg during transferring from PS access to 

CS access 

When SCC AS receives a SIP BYE request on the Source Access Leg with the Reason header field containing a SIP 
503 (Service Unavailable) response code then: 

if the SCC AS receives an II Invite message within a time defined by the operator policy after the SIP BYE 
request reception, then the SCC AS shall not initiate release of the dialog toward the the remote UE; and 

if the SCC AS does not receive a II Invite message within a time defined by the operator policy after the SIP 
BYE request reception then the SCC AS shall initiate release of the dialog toward the the remote UE. 

NOTE: 8 seconds is an appropriate value for the operator policy. 
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6.2.5.5 Service continuity after transferring multiple calls from PS access to CS 

access using SRVCC 

6.2.5.5.1 General 

The ICS UE, that has previously used the Gm reference point to estabhsh muhiple active or held calls that are currently 
using a single CS bearer as a result of completion of SRVCC procedure, shall transfer the service control signalling 
from the Gm reference point to the II interface for each call while retaining the existing single CS bearer. 

6.2.5.5.2 Detailed behaviour of ICS UE 

The ICS UE shall follow the procedures as specified in subclause 6.2.5.2.1 for each call. 

6.2.5.5.3 Detailed behaviour of SCC AS 

The SCC AS shall follow the procedures as specified in subclause 6.2.5.2.2 for each call. 

6.2.6 Assignment of single CS bearer to 11 sessions 

6.2.6.1 General 

When the ICS UE wants to set up a new call using the II protocol, and if there is an existing CS bearer leg (i.e. between 
the ICS UE the MSC/MGCF) that has been previously establish either by the ICS UE or the SCC AS, and there are no 
active II sessions using the existing CS bearer leg (all II sessions using the existing CS bearer leg are on hold), the ICS 
UE can use the existing CS bearer leg for the new call. Likewise, for the incoming call destined for the serving ICS UE, 
the SCC AS can indicate to the ICS UE to use an existing CS bearer leg for the ICS UE terminated call, if there are no 
active II sessions using the existing CS bearer leg (all II sessions associated with the existing CS bearer leg are on 
hold). In either case, once the new II session is set up, the existing CS bearer leg (i.e. between the ICS UE the 
MSC/MGCF) will be concatenated with a new IP bearer leg to form an end-to-end connection for media for the new 
call between the ISC ICS UE and the remote endpoint. 

When either ICS UE or the SCC AS initiate the set up of an II session that will use an existing CS bearer leg (i.e. 
between the ICS UE the MSC/MGCF) for media, it is assumed that there is a single existing CS bearer leg between the 
ICS UE and the MSC/MGCF. Hence, neither the ICS UE nor the SCC AS will have to explicitly specify which existing 
CS bearer leg will be used for the call. The ICS UE and the SCC AS implicitly assume that the single existing CS 
bearer leg is used for the new call being set up. When a call that was on hold is resumed, the SCC AS ensure that the 
respective end-to-end connection for media associated with the resumed call is also restored, i.e. the existing CS bearer 
leg is re-allocated to the resumed call and re-concatenated to the IP leg associated with the resumed call. 

6.2.6.2 Originating call behaviour 
6.2.6.2.1 Detailed behaviour of ICS UE 

Prior to initiating the establishment of a new II session as described in this subclause, the ICS UE ensures that there is 
only one existing CS bearer leg between the ICS UE and the MSC/MGCF. If there is either none or more than one 
existing CS bearer leg between the ICS UE and the MSC/MGCF, the ICS UE shall not initiate the establishment of an 
II session as described in this subclause. 

When the ICS UE wants to establish a new II session that uses an existing CS bearer leg between the ICS UE and the 
MSC/MGCF, the ICS UE shall send an II Invite message toward the SCC AS, and populate the II Invite message as 
specified in subclause 6.2.1.2.1.2 with the following additions: 

1) set the Reason in the II Invite message to value hex "003", as specified in table 7.3.1. This value indicates to the 
SCC AS that the existing CS bearer leg will be used for this call. 

If the ICS UE receiving an II Progress message with Progress reason set to Call progressing from the SCC AS, the ICS 
UE shall behave as specified in subclause 6.2.1.2.1.3 with the following addition: 

1) ignore the SCC AS PSI DN, if included in the II Progress message with Progress reason set to Call progressing 
received from the SCC AS, i.e. the ICS UE shall not initiate a call toward the CS domain. 
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NOTE 1 : The ICS UE will not initiates the call setup over the CS domain for the purpose of setting up a new CS 
bearer leg, since the existing CS bearer leg will be used for the call being established. 

When the ICS UE receives an II Progress message with Progress reason set to 180 the ICS UE shall: 

1) provide an alerting indication to the user. 

NOTE 2: If in-band alerting is not provided via the CS bearer, the ICS UE will provide local alerting. 

When the ICS UE receives an II Success message from the SCC AS, the ICS UE shall behave as specified in 
subclause 6.2.1.2.1.5 with the following addition: 

1) the ICS UE shall not expect to receive a CONNECT message from the CS domain as specified in 
3GPP TS 24.008 [3] since it did not send a SETUP message toward the CS domain; and 

2) consider the II session as being established and the existing CS call leg as being assigned to this II session. 

6.2.6.2.2 Detailed behaviour of SCC AS 

Prior to initiating the establishment of an II session as described in this subclause, the SCC AS shall insure that there is 
only one existing CS bearer leg between the ICS UE and the MSC/MGCF. If the SCC AS receives an II Invite message 
from the ICS UE that includes a Bearer information element that contains a Reason field set to value hex "003", as 
specified in table 7.3.1, and if there is either none or more than one existing CS bearer leg between the ICS UE and the 
MSC/MGCF, the SCC AS shall reject the request for the II session establishment. 

If a new call request destined for the ICS UE arrives at the SCC AS during the establishment of an II session as 
described in this subclause, the SCC AS shall reject this request by immediately responding with a busy indication to 
the new incoming call. 

If the SCC AS receives an initial II Invite message with the Reason set to value hex "003", as specified in table 7.3.1 
that indicates to the SCC AS that the existing CS bearer leg will be used for this call, and there is only one existing CS 
bearer leg between the ICS UE and the MSC/MGCF, the SCC AS shall behave as specified in subclause 6.2.1.3.1.2 
with the following addition: 

1) interpret the received II Invite message with the Reason set to value hex "003" as a request to use the existing 
CS bearer leg when setting up an end-to-end connection for media toward the called user. 

The SCC AS may send the II Progress message with Progress reason set to Call progressing towards the originating 
ICS UE. If the SCC AS sends the II progress message toward the originating ICS UE, the SCC AS shall populate the II 
Progress message with Progress reason set to Call progressing as specified in subclause 6.2.1.3.1.3 with the following 
addition: 

1) the SCC AS shall not include the SCC-AS-id information element that contains an allocated SCC AS PSI DN in 
the II Progress message with Progress reason set to Call progressing. 

NOTE 1: The reason for sending the II Progress message with Progress reason set to Call progressing, is to 

increase the retransmissions timer at the ICS UE, if an unreliable transport-layer connection is used (see 
subclause 7.5.3.2.1.1.2). 

Subsequently, the SCC AS shall: 

1) send a SIP re-INVITE request toward the CS domain (i.e. the MGCF) that does not contain an SDP offer; and 

2) upon receiving a SDP offer from the CS domain (in the response to the SIP re-INVITE request), send an initial 
SIP INVITE request toward the the remote UE. The SDP offer included in the SIP INVITE request sent toward 
the the remote UE contains the information in the SDP offer received from the CS domain. 

Upon receiving the SIP 180 (Ringing) response from the remote UE, the SCC AS shall send an II Progress message 
with Progress reason set to 180 towards the originating UE, as specified in subclause 6.2.1.3.1.4 with the following 
addition: 

1) if this is the first II Progress message (i.e. the SCC AS did not previously sent an II Progress message with 
Progress reason set to Call progressing), the SCC AS shall also include (in the II Progress message with 
Progress reason set to 180) all information elements as specified in subclause 6.2.1.3.1.3, except the SCC AS PSI 
DN. 
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Upon receiving a SIP 200 (OK) response from the remote UE, the SCC AS shall: 

1) send the SIP ACK request towards the CS domain that includes a SDP answer received from the remote UE. 
The SDP answer sent towards the CS domain contains the media information that has been received in the SDP 
answer from the remote UE; and 

2) send an II Success message toward the ICS UE over the II interface as specified in the subclause 6.2.1.3.1.5, 
and a SIP ACK toward the remote UE. 

6.2.6.3 Terminating call behaviour 

6.2.6.3.1 Detailed behaviour of ICS UE 

Prior to accepting a request for an II session as described in this subclause, the ICS UE ensures that there is only one 
existing CS bearer leg between the ICS UE and the MSC/MGCF. If there is either none or more than one existing CS 
bearer leg between the ICS UE and the MSC/MGCF, the ICS UE shall reject the request for the II session 
establishment. 

If the ICS UE receives an initial II Invite message with the Reason set to value hex "003", as specified in table 7.3.1 
that indicates to the ICS UE that the existing CS bearer leg will be used for this call, and there is only one existing CS 
bearer leg between the ICS UE and the MSC/MGCF, the ICS UE shall behave as specified in subclause 6.2.1.2.2 with 
the following addition: 

1) interpret the received II Invite message with the Reason set to value hex "003" as a request to use the existing 
CS bearer leg for this call; and 

2) ignore the SCC AS PSI DN, if included in the II Invite message received from the SCC AS, i.e. the ICS UE 
shall not initiate a call toward the CS domain. 

NOTE 1 : The ICS UE will not initiates the call setup toward the CS domain for the purpose of setting up a new CS 
bearer leg, since the existing CS bearer leg will be used for the call being established. 

Subsequently, the ICS UE shall allert the user and generate an II Progress message with Progress reason set to 180 and 
send it towards the SCC AS, as specified in subclause 6.2.1.2.2. 

If the user accepts the call, the ICS UE shall generate an II Success message and send it towards the SCC AS, as 
specified in subclause 6.2.1.2.2. 

6.2.6.3.2 Detailed behaviour of SCC AS 

Prior to initiating the establishment of an II session toward the ICS UE as described in this subclause, the SCC AS 
ensures that there is only one existing CS bearer leg between the ICS UE and the MSC/MGCF. If there is either none or 
more than one existing CS bearer leg between the ICS UE and the MSC/MGCF, the SCC AS shall not initiate the 
establishment of an II session toward the ICS UE as described in this subclause. 

If a new call request destined for the ICS UE arrives at the SCC AS during the establishment of an II session as 
described in this subclause, the SCC AS shall reject this request by immediately responding with a busy indication to 
the new incoming call. 

When the SCC AS, upon receiving an initial SIP INVITE request from the remote UE destined for the served ICS UE, 
wants to establish a new II session toward the ICS UE that uses an existing CS bearer leg between the ICS UE and the 
MSC/MGCF, the SCC AS shall send an II Invite message toward the ICS UE. The SCC AS shall populate the II Invite 
message as specified in subclause 6.2.1.2.23.2.1 with the following additions: 

1) set the Reason in the II Invite message to value hex "003", as specified in table 7.3.1. This value indicates to the 
ICS UE that the existing CS bearer leg will be used for this call; 

2) not include the SCC-AS-id information element that contains an allocated SCC AS PSI DN in the II Invite 
message; and 

3) send a SIP re-INVITE request toward the CS domain (i.e. MSC/MGCF) that contains an SDP offer received in 
a SIP INVITE request from remote UE. 
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When the SCC AS received an II Progress with Progress reason set to 180 from the UE, the SCC AS shall send a SIP 
180 (Ringing) response to the remote UE. 

When the SCC AS receives SIP 200 (OK) response from the CS domain that contains an SDP answer and an II Success 
message from the ICS UE, the SCC AS shall send a SIP 200 (OK) response to the remote UE that contains an SDP 
answer received from the CS domain. At this stage the SCC AS considers the II session as being established and an 
end-to-end bearer being set up (i.e. the CS call leg as being assigned to this II session). 

6.3 Supplementary services control procedures 

6.3.0 Introduction 

The II protocol provides a method for a UE and SCC AS to control supplementary services the following ways: 

1) Once the UE invokes a mid-call supplementary service from the MSC (via the CS bearer leg) using existing the 
CS procedures for a call that was previously established without using either the Gm or the II interfaces, then for 
all subsequent calls the UE and SCC AS shall invoke the mid-call supplementary services from the MSC (via the 
bearer leg) using existing the CS procedures, until all calls have been cleared. 

2) Once the UE and the SCC AS invoke a mid-call supplementary service using the II protocol for a call that was 
previously established via the CS bearer leg without using either the Gm or the II interfaces, and the II call 
control is maintained (the control is not transferred to Gm interface), then for all subsequent calls that are 
established without using either the Gm or the II interfaces, the UE and SCC AS shall invoke the mid-call 
supplementary services using the II protocol, until all calls have been cleared. 

3) If an existing call was previously established via the CS bearer leg using the II interface and call control is via 
the II interface, the UE and SCC AS shall then mid-call supplementary service shall be invoked using II 
protocol. 

4) If the UE and the SCC AS invoke a mid-call supplementary service for a call that was established via the CS 
bearer leg using the Gm reference point, and if (due to service continuity procedures) the call control is 
transferred to the II control, then the II protocol may be used to provide subsequent mid-call supplementary 
services for this call (e.g. a voice call that was placed on hold using Gm interface may be resumed using the II 
interface). 

5) If the UE and the SCC AS invoke a mid-call supplementary service using the II protocol, and if (due to service 
continuity procedures) the call control is transferred to the Gm interface, then the Gm interface may be used to 
provide subsequent mid-call supplementary services for this call (e.g. a voice call that was placed on hold using 
the II protocol may be resumed using the II interface). 

6.3.1 Line ID Services (OIP, OIR, TIP, TIR) 

6.3.1.1 Originating Identity Presentation (OIP) 

The procedures in subclause 6.2.1.2.1 apply. The From-id information element is used to present the originating 
identity. 

6.3.1 .2 Originating Identity Restriction (OIR) 

The procedures in subclause 6.2.1.2.1 apply with following addition: 

1) a Privacy information element that indicates the ICS UE wants to restrict the presentation of the originating 
identity. 

6.3.1.3 Terminating Identity Presentation (TIP) 

The procedures of sending an II Success message towards the orginating UE in subclause 6.2.1.3.1 apply with 
following addition: 
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1) a To-id information element that includes either a SIP URI or an E.164 number, and will be used to present the 
terminating identity. 

6.3.1.4 Terminating Identity Restriction (TIP) 

The procedures of sending an II Success message towards the orginating UE in subclause 6.2.1.3.1 apply without a To- 
id information element. 

6.3.2 Communication diversion services (CDIV) 

6.3.2.1 Communication Forwarding Unconditional (CFU) 

No specific II related messages. 

6.3.2.2 Communication Forwarding on Not Logged-in (CFNL) 

No specific II related messages. 

6.3.2.3 Communication Forwarding Busy (CFB) 

If the ICS UE receives an II Invite message from the SCC AS, and the UE determines that the user is busy, the ICS UE 
shall: 

1) generate an II Failure message that includes: 

a) a Message Type set to indicate that this is an II Failure message; 

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 

NOTE 1: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first II message sent to 
the SCC AS. Otherwise the previously set Call-Identifier value is used. 

c) increment the stored message sequence value, store it, and include it in the Sequence-ID; and 

d) set the Error-Code information element to 486; and 

2) send the II Failure message towards the SCC AS over the transport layer connection over which the II Invite 
message was received. 

6.3.2.4 Communication Forwarding No Reply (CFNR) 

No specific II related messages. 

6.3.2.5 Communication Forwarding on Subscriber Not Reachable (CFNRc) 

If the ICS UE receives an II Invite message from the SCC AS, and the UE determines that the user is busy, the ICS UE 
shall: 

1) generate an II Failure message that includes: 

a) a Message Type set to indicate that this is an II Failure message; 

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 

NOTE 1: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first II message sent to 
the SCC AS. Otherwise the previously set Call-Identifier value is used. 

c) increment the stored message sequence value, store it, and include it in the Sequence-ID; and 

d) set the Error-Code information element to 480; and 
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2) send the II Failure message towards the SCC AS over the transport layer connection over which the II Invite 
message was received. 

6.3.2.6 Communication Deflection (CD) 

If the ICS UE receives an II Invite message from the SCC AS, and the UE determines that deflect the call, the ICS UE 
shall: 

1) generate an II Redirection message that includes: 

a) a Message Type set to indicate that this is an II Failure message; 

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 

NOTE 1: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first II message sent to 
the SCC AS. Otherwise the previously set Call-Identifier value is used. 

c) increment the stored message sequence value, store it, and include it in the Sequence-ID; and 

d) To-id information element set to either a SIP URI or an E. 164 of the C-party identity; and 

2) send the II Redirection message towards the SCC AS over the transport layer connection over which the II 
Invite message was received. 

6.3.2.7 Communication Diversion Notification (CDIVN) 

If the SCC AS wants to notify the ICS UE that the call was diverted, the SCC AS shall: 

1) generate an II Notify message that includes: 

a) a Message Type set to indicate that this is an II Notify message; 

b) increment the stored message sequence value, store it, and include it in the Sequence-ID; and 

c) a Mid-call information element that indicates that the call was diverted; and 

2) send the II Notity message towards the ICS UE over the transport layer connection over which other II message 
was received. 

6.3.3 Communication Barring 

No specific II related messages. 

6.3.4 Communication Hold (HOLD)/Resume 
6.3.4.1 Actions at the ICS UE 

When the ICS UE wants to hold/resume an II session using an Ilreference point, the UE shall: 

1) generate an II Mid call Request message that includes: 

a) a Message Type set to the value that indicates that this is an II Mid call Request message, as specified in 
table 7.3.1; 

b) increment the stored message sequence value, store it, and include it in the Sequence-ID field; and 

c) set the Mid-call information element that indicates the ICS UE wants to either hold or resume the II session 
as specified in table 7.4.2.12.1; and 

2) forward the II Mid call Request message toward the SCC AS. 
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Upon receiving an II Success message from the SCC AS, the ICS UE shall consider that the II session has been either 
placed on hold or resumed, as requested. 

If the ICS UE receiving an IlMid call Request message with the Mid-call infromation element, that indicates that the II 
session was either placed on hold or resumed, the ICS UE shall: 

1) store the information received in the II Mid call Request message; 

2) generate an II Success message containing the following information: 

a) a Message type field set to the value that indicates that is an II Success message; 

b) the stored Call-ID header value; 

c) add one to the stored Sequence-ID field value. Store it, and include it in the Sequence-ID header value; and 

3) send the II Success message towards the SCC AS over the transport layer connection over which the II Mid Call 
Request message was received. 

6.3.4.2 Actions at the SCC AS 

Upon receiving an IlMid call Request message with a Mid-call infromation element, that indicates the II session to be 
either held or resumed, from the ICS UE via the II reference point, the SCC AS shall: 

1) store the information received in the II Mid call Request message; 

2) perform the standard SIP procedures toward the far end and the MGCP in order to either inactive or active the 
RTP media. 

Upon remote UE accepting the inactivation or activation of the RTP media, the SCC AS shall: 

1) generate an II Success message containing the following information: 

a) a Message type field set to the value that indicates that is an II Success message; 

b) the stored Call-ID header value; 

c) add one to the stored Sequence-ID field value. Store it, and include it in the Sequence-ID header value; and 

2) send the II Success message towards the originating ICS UE over the transport layer connection over which the 
II Mid Call Request message was received. 

When the SCC AS wants to hold/resume an II session using an Ilreference point, the SCC AS shall: 

1) inactivating or activating the RTP media by performing the standard SIP procedures toward the far end and the 
MGCP); 

2) generate an II Mid call Request message that includes: 

a) a Message Type set to the value that indicates that this is an II Mid call Request message, as specified in 
table 7.3.1; 

b) increment the stored message sequence value, store it, and include it in the Sequence-ID field; and 

c) set the Mid-call information element that indicates the II session was either placed on hold or resumed; 

3) forward the II Mid call Request message toward the ICS UE. 

Upon receiving an II Success message from the ICS UE, the SCC AS shall consider that the II session has been either 
placed on hold or resumed, as requested. 
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6.3.5 Consultative Explicit Communication Transfer 

6.3.5.1 Actions at the ICS UE 

When ICS UE A is playing the role of transfer, the ICS UE shall: 

1) generate an II Refer message that includes: 

a) a Message Type set to indicates that this is an II Refer message; 

b) increment the stored message sequence value, store it, and include it in the Sequence-ID; and 

c) a Mid-call information element that indicates that this is a conference invitation; and 

2) forward the II Mid Call message toward the SCC AS. 

6.3.5.2 Actions at the SCC AS 

Upon receiving an IlMid call request message with a Mid call informtion element indicating this is a conference 
invitation from the ICS UE via the II reference point, the SCC AS shall continue session establishment towards the 
conference AS as specified in 3GPP TS 24.173 [18]. 

Upon receiving a SIP 200 OK response from conference AS, the SCC AS shall: 

1). generate an II Success message containing the following information: 

a) a Message Type set to indicate that is an II Success message; and 

b) a Call-Identifier field containing the Call-Identifier value that uniquely identifies this II session between the 
UE and SCC AS; 

2) add one to the stored message sequence value. Store and include the Sequence-ID; and 

3) send the II Success message towards the originating UE over the transport layer connection over which the II 
Mid call request message was received. 

6.3.6 Conference calling (CONF) 

6.3.6.0 General 

The conference calling (CONF) service consists of conference creation, joining a conference, inviting others to join a 
conference and leaving a conference, as described in 3GPP TS 24.147 [21] and 3GPP TS 24.605 [22]. 

6.3.6.1 Actions at the ICS UE 

When the ICS UE is creating a conference, the ICS UE shall send an II Invite message addressed to the E.164 identity 
that corresponds to the Conference factory URL Upon receipt of the II Success message, the ICS UE is considered to 
have joined the conference, in the same manner as receipt of a SIP 200 (OK) response is treated in the procedures 
described in 3GPP TS 24.147 [21]. 

When ICS UE is inviting others to join a conference, the ICS UE shall: 

1) generate an II Refer message that includes: 

a) a Message type set to indicate that this is an II Refer message; 

b) a Sequence-ID information element, that includes a message sequence value, having first added one to the 
stored value, and stored it again; 

c) a To-id information element that includes to the E. 164 identity that corresponds to the Conference factory 
URI; and 
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d) a Replaces information element is optionally included, as described for the equivalent usage of the Replaces 
header field in subclause 4.5.2.1.2 of 3GPP TS 24.605 [22]; and 

2) forward the II Refer message toward the SCC AS. 

When the ICS UE receives an II Success message, the UE shall: 

1) verify if a II session exists for the received Call-Identifier value; 

2) verify if a the message is in sequence according to the message sequence number value contained in the 
Sequence-ID information element; and 

3) consider the invitation for another party to join the conference as successful. 

When the ICS user would like to leave the conference, the ICS UE shall generate an II Bye message. 

6.3.6.2 Actions at the SCC AS 

Upon receiving an II Invite message from the ICS UE on the respective II session for the purposes of conference 
creation, the SCC AS shall follow the procedures in subclause 6. 2.1. 3. lof this document for session origination. 

NOTE: The conference focus AS will provide the conference creation functions described in subclause 5.3.2.3 of 
3GPPTS 24.147 [21]. 

Upon receiving an II Refer message from the ICS UE on the respective II session, the SCC AS shall: 

1) generate a SIP REFER request towards the conference focus AS; and 

2) upon receipt of a SIP 200 (OK) response in response to the SIP REFER request sent to the conference focus AS, 
generate an II Success message containing the following information: 

a) a Message Type set to indicate that is an II Success message; and 

b) a Call-Identifier information element containing the value that uniquely identifies this II session between the 
UE and SCC AS; 

c) a Sequence-ID information element, having first added one to the stored message sequence value and stored 
it again; and 

4) send the II Success message towards the originating UE over the transport layer connection over which the II 
Refer message was received. 

Upon receipt of an II Bye message from the ICS UE via on the respective II session for purposes of leaving a 
conference, the SCC AS shall follow the procedures in subclause 6.2.3.3.3 of this document for session release. 

6.3.7 Communication Waiting 

6.3.7.1 Actions at the ICS UE 

Upon receipt of an II Invite with a Reason Value set to 0x005 (CW), the ICS UE shall follow the procedure described 
in subclause 4.5.5.3.2 of 3GPP TS 24.615 [23], treating the II Invite with a Reason value of 0x005 (CW) in the same 
way as receipt of a SIP INVITE request with an XML body and a Content-Type header field set to 
" application/vnd. 3gpp . c wH-xml" . 

For Case A of subclause 4.5.5.3.3 of 3GPP TS 24.615 [23], the ICS UE shall send a II Success message to indicate an 
answer of the waiting communication. The ICS UE shall follow explicit procedures to hold or release the active session 
while doing so. For Case B, of subclause 4.5.5.3.3 of 3GPP TS 24.615 [23], the ICS UE shall send an II Failure 
message with the Error-Code information element set to the equivalent of 480 to indicate that the user has not answered 
the waiting communication. 

6.3.7.2 Actions at the SCC AS 

Upon receipt of a SIP INVITE request destined for an ICS UE with an XML body and a Content-Type header field set 
to "apphcation/vnd.3gpp.cwH-xml" as described in subclause 4.5.5.2 of 3GPP TS 24.615 [23], the SCC AS shall send 
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the II Invite message as specified in subclause 6.2.1.3.2 or subclause 6.2.1.3.3 of this document with an II Invite 
Reason value set to 0x005 (CW). 

6.4 sec AS and ICS UE Time Synchronization 

6.4.1 General 

In order to detect stale II messages transmitted when non-real time transport layer protocols are used, the ICS UE and 
sec AS must be synchronized in time. The staleness of the II messages can be determined by the following two steps: 

1) The ICS UE originates initial time synchronization procedure with the SCC AS. During this procedure both ICS 
UE and SCC AS receive an initial time of the peer. The time value is measured in seconds. The initial time value 
is not important as long as the subsequent time measurements are increased accordingly; and 

2) An II message receiver (ICS UE or SCC AS) compares the time received in an II message i.e. the current time 
of the peer with the initial time established in step 1, and based on the time difference between the current and 
initial time it makes a decision about the staleness of the message. If the message is stale it shall be discarded 
and no response generated to the II message. 

6.4.2 Generating Time 

The initial time value can be initialized using one of the following methods: 
i) a local time of the machine or terminal; 
ii) a randomly generated time; and 
ii) zero. 

6.4.3 Detailed behaviour of ICS UE 

If time synchronization is supported by the UE (i.e. when the II messages are transmitted over non-real time transports) 
the time synchronization procedure shall be initiated by the ICS UE after the non-real time transport layer connection is 
established. The time synchronization procedure with the SCC AS may be repeated by the ICS UE, if required and 
supported. 

6.4.3.1 ICS UE Synchronization Origination 

When the ICS UE initiates the synchronization procedure using an Ilreference point, the UE shall: 

1) generate an II Notify message that includes: 

a) a Message Type set to indicate that this is an II Notify message and Reason field in the II Notify message set 
to value hex "001", that indicates that the II Notify message is used for synchronization, as specified in 
table 7.3.1; 

b) a new value in the Call-Identifier field (Part-1), as specified in subclause 7.2.2. The Call-Identifier value will 
uniquely identify this II session between the ICS UE and the SCC AS; 

c) an allocated Sequence-ID; 

d) a From-id information element that includes either a SIP URI or an E.164 number, and it will be used by the 
SCC AS to identify the ICS UE; and 

e) a Timestamp information element that includes the initial time generated according to the subclause 6.4.2. 
The element will be used by the SCC AS to validate the ICS UE II messages. The Timestamp value is stored 
by the ICS UE. 

2) select the transport layer protocol (see subclause 4.2.3) depending on the access network type, and forward the II 
Notify message toward the SCC AS. 

When the ICS UE receives an II Success message, the UE shall: 
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3) verify if a II session exists for the received Call-Identifier field value; 

4) verify if a the message is in sequence according to the value of the Sequence-ID; and 

5) retrieve and store the Timestamp information element value received in the response. 

If the ICS UE does not receive an II Success message or an II Failure message within 64*T1 seconds, the UE shall 
consider the II Notify message as failed and it may attempt to perform the synchronization procedure again after an 
interval of time. However, if the ICS UE receives an II Failure message (with Reason valus set to 488, as specified in 
table 7.3.1) indicateing the the SCC AS does not support the synchronization procedure, the ICS UE shall not attempt to 
perform the synchronization procedure again. 

6.4.4 Detailed behaviour of SCC AS 
6.4.4.1 SCC AS Synchronization Termination 

Upon receiving an II Notify message with Reason field in the IlNotify message set to value hex "001", as specified in 
table 7.3.1, from the ICS UE via the II reference point, the SCC AS shall either: 

A) respond with an II Failure message (with Reason valus set to 488, as specified in table 7.3.1), if the SCC AS 
does not support the synchronization procedure; or 

B) if the SCC AS supports the synchronization procedure: 

1) retrieve the ICS UE time value from the Timestamp information element of the II Notify message, and store 
the value; 

2) save the received Call-Identifier field value and Sequence-ID values and use them for further reference to this 

session; 

3) generate an II Success message containing the following information: 

a) a Message Type set to indicate that is an II Success message; 

b) a Call-Identifier field with the stored Call-ID field value; 

c) add one to the stored message sequence value. Store and include the Sequence-ID; 

d) include the Timestamp information element that is generated according to the subclause 6.4.2. The 
element will be used by the ICS UE to validate the SCC AS II messages. The Timestamp value is stored 
by the SCC AS. 

4) send the II Success message towards the originating UE over the transport layer connection over which the 
II Notify message was received. 



7 Protocol specification and implementation 

7.1 Overview of 11 protocol functionality 

The II protocol includes the procedures for establishing, maintaining, and clearing the II sessions between the ICS UE 
and the SCC AS (see figure 7.1). 
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Figure 7.1 UE session signalling and bearer path using II interface for Service Control Signalling 

Path 

NOTE 1: Figure 7.1 illustrates an MSC server that is not enhanced for ICS. 11 can also be used when deploying an 
MSC server enhanced for ICS as specified in 3GPP TS 23.292 [2]. 

The 11 protocol is a message based point-to-point protocol. The II protocol messages are wrapped in a point-to-point 
transport layer connection protocol (e.g. USSD) and are exchanged between the ICS UE and the SCC AS. Therefore, 
the 11 protocol does not include any routing capabilities. To address the ICS UE in CS network and establish a 
transport-layer connection, (the lUA of) the SCC AS shall convert the called party identity (i.e., IMS public user 
identity) to the CS domain party identity that is required to route the transport layer protocol(i.e., MSISDN, MDN, etc.). 

The 11 protocol assumes that there is an associated connection-control protocol that incorporates media negotiation 
capabilities and provides the setting up and clearing of the connection over which the media will be exchanged. 
Therefore, any signalling between the UE and the CS access domain (see figure 7.1), as well as the SIP signalling 
between the MGCF and the SCC AS should be viewed as a procedure to establish a media connection rather then a call 
control signalling. Obviously, the 11 endpoints will correlate and synchronize the progress of the 11 session 
establishment and clearing of the 11 session with the associated media-establishing procedures. 

NOTE 2: The primitives that are used to communicate between the 11 protocol 11 session entity and the associated 
connection-control protocol entity, internally in the UE and SCC AS, respectively, are not specified in 
this document. 

The 11 protocol assumes that the application level segmentation of the 11 protocol messages is not supported. The size 
of the 11 protocol messages is constrained by the limits of the transport-layer message size. For example, USSD allows 
for a message size of 160 octets. This means that it is not possible to send an 11 protocol message greater than 160 
octets, unless message segmentation is designed into the 11 protocol. A USSD dialogue is already segmented by the use 
of USSD sub-dialogues as a USSD conversation, and this usage of USSD is inappropriate for the 11 protocol. 

The 11 protocol is a transport-independent protocol, i.e. the 11 protocol 11 session control entities can exchange the 11 
protocol messages over any transport-layer connection that connects the ICS UE and the SCC AS. The ICS UE sends 
the 11 protocol messages to the SCC AS over a transport-layer connection (e.g. USSD) that the ICS UE knows it will 
reach the SCC AS. Likewise, The SCC AS sends the 11 protocol messages to the ICS UE over a transport-layer 
connection (e.g. USSD) that the SCC AS knows that it will reach the ICS UE. For example, the SCC AS forwards the 
11 protocol message to the ICS UE over the same transport-layer connection (e.g. USSD) over which it received the 
previous 11 protocol message from the ICS UE. 

The 11 protocol message are self-identifying, i.e. the information contained in the 11 protocol message uniquely 
identifies the call to which the 11 protocol message pertains to. 

The 11 protocol assumes that when the transport-layer connection is established between the UE and SCC, the UE's 
E.164 number is bound to the respective transport-layer connection at both the UE and SCC AS (e.g. the establishment 
of an USSD channel can implicitly bind the UE's E.164 number to this transport-layer connection). Subsequently, the 
request for an 11 session destined for the respective E.164 number will be passed to the UE over the respective 
transport-layer connection. 

NOTE 3: Since the binding between the transport-layer connection and the E.164 number is performed when the 
transport-layer connection is established, the 11 protocol does not include any registration procedure. 

The 11 protocol is a binary-oriented protocol (i.e. the 11 messages are binary encoded). The bit-map tables are used to 
describe the 11 messages and associated information elements. 
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In this release of this document, it is assumed that the ICS UE, when establishing a transport-layer connection (e.g. 
USSD channel) to the SCC AS, will have been authenticated by the CS domain. Due to a relationship between the SCC 
AS and the CS domain, the ICS UE is not authenticated (e.g. challenged) by the SCC AS when sending any II protocol 
message to the SCC AS. However, the SCC AS will check the UE identity for potential invalid IMS public user identity 
included by the ICS UE. The CS domain number received from the transport-layer is trustable and will be used by (the 
lUA of) the SCC AS to check the URI of the UE before the SCC AS provides SIP UA behaviour on behalf of the ICS 
UE. 

7.2 11 -protocol messages and functional definition 
7.2.1 II -protocol messages 



7.2.1.1 



General 



This subclause provides the list of Il-protocol messages (see table 7.2.1) and brief description of each Il-protocol 
message. Based on their function the Il-protocol messages can be grouped into five categories: 

Il-Session establishment messages; 

- 1 1 -Stable Session messages; 

Il-Session clearing messages; 

1 1 -Error messages; 

II- Supplementary Service -Invocation messages; and 

II -Other messages. 

Table 7.2.1.1 : Il-protocol messages 



Message type 


Description and 

content 

(subclause) 


Session establishment messages: 


7.2.1.2 


11 Invite message 
11 Progress message 
11 Success message 








Stable Session messages: 


7.2.1.3 


11 Refer message 




Session clearing messages: 


7.2.1.4 


11 Bye message 
11 Success message 




Error messages: 


7.2.1.5 


11 Failure message 




Supplementary Service Invocation messages: 


7.2.1.6 


11 Mid Call Request message 
11 Redirection message 




Other messages: 


7.2.1.7 


11 Notify message 




11 Dummy message 





7.2.1.2 



Session establishment messages 



The session establishment II messages can be sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS 
UE. 
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II Invite message 

The II Invite message is sent either by the calling UE to the SCC AS or by the SCC AS to the called UE to initiate 
session establishment. 

II Progress message 

The II Progress message is a general purpose provisional response, semantically similar to SIP Ixx class responses. The 
binary Reason field value (per figure 7.3.1) corresponds with the received SIP Ixx response's numeric status-code 
value. 

II Success message 

The II Success message indicates that the action requested in the respective II message has been accomplished 
successfully. 

The II Success message: 

is transmitted by the SCC AS to the calling UE to indicate that the session has been accepted; or 

is transmitted by the called UE to the SCC AS to indicate that the called UE has accepted the session. 

The Reason's corresponding to the II Success message are specified in table 7.3.1 and correspond with a SIP 2xx 
response's numeric status-code. 

7.2.1 .3 Stable session messages 

II Refer message 

The II Refer message is sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS UE to indicate that the 
recipient of the II Refer message should contact the target identified in the Refer-to information element included in the 
II Refer message. 

7.2.1.4 Session clearing messages 

II Bye message 

The II Bye message: 

is transmitted by the SCC AS to the ICS UE to clear the II session; or 
is transmitted by the ICS UE to the SCC AS to clear the II session. 

7.2.1.5 Error messages 

II Failure message 

An II Failure response message is sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS UE, to 
indicate that an error has occurred. The additional parameters included in the II -Failure message indicate the type of the 
error that has occurred. The reason value field is a direct one to one mapping to the status code in the status line as 
specified in subclause 7.2 of RFC 3261 [6]. 

7.2.1 .6 Supplementary Services Invocation related messages 

The following section details the messages that are used to request the invocation of a supplementary service. 

II Mid Call Request message 

The II Mid Call Message is used for the invocation of mid-call supplementary services. For example: user wishes to 
hold or resume a call. 

II Redirection message 
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The II Redirection message is used by the ICS UE to inform the SCC AS of the desire to invoke a supplementary 
service, in response to incoming signalling. For example: desire for the called user to deflect the call to a third party. 
The SCC AS interworks the II response to the appropriate SIP response to send to the SIP AS. 

7.2.1 .7 Other messages 

II Notify message 

The II Notify message may be used to notifyeither by the ICS UE or the SCC AS to inform its peer about some event 
that has occurred or to convey some information to its peer, e.g.of events related to the invocation of supplementary 
services. For example: 

Notification that a call has been forwarded to a third party; 

Notifications related to Explicit Call Transfer; or 

Notifications related to requests to join a Conference. 

II Dummy message 

The II Dummy message is only used for those specific transport-layer connections (e.g., USSD) which provide two- 
way-alternative interactive service. If the party which has the turn hasn't sent an application level protocol message for a 
specific time, an II Dummy message shall be delivered to the counterpart to transfer the turn with the consideration of 
not delaying its transmission of application protocol message. 

7.2.2 11 message Structure and common field encoding 
7.2.2.1 General 



7.2.2.1.1 



Message Header structure 



The II message structure is shown in figure 7.2.2.1. Each II messages consists of two parts, i.e. the first part referred to 
as the II message common part and the second part consisting of zero or more II information elements. The II message 
common part is included in every II message. The II information elements that are included in an II message depend 
on a type of II message being sent. 

The text in this clause describes the content of the II message common part. The octet number 1 (shown at the top of 
the figure 7.2.2.1) is sent first followed by octet 2, 3, etc. Within each octet, the bit designated "bit 1" is transmitted 
first, followed by bits 2, 3, 4, etc. 



8 7 6 5 


4 3 2 1 


Octet 


Protocol version number 


Protocol identifier 


1 


Message type R Reason 


2 


Reason 


3 


Call-Identifier (Part-1) 


4 


Call-Identifier (Part-2) 


5 


Call-Identifier (Part-2) 


6 


Sequence-ID 


7 


Information element #1 




Information element #2 



Figure 7.2.2.1 : II message structure 



7.2.2.1.2 



Protocol Version information 



The first octet is divided into two four-bit subfields, i.e. the Protocol identifier and the Protocol version number. The 
Protocol identifier for II protocol is "0001" and indicates that the respective message, transported across the transport- 
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layer connection, is an II protocol message. The Protocol version number indicates that this is the first version of this 
specification and the respective value of the Protocol version number subfield is "0001". 

7.2.2.1 .3 Message Type and Reason 

The second octet and third consists of five-bit Message Type field that identifies the type of the II message, while the 
ten-bit Reason fields provide additional information about the respective II message, e.g.. Progress reason value, as 
specified in table 7.2.2.1. The bit number 3 in the second octet (marked "R") is reserved for future use. 

7.2.2.1.4 Call Identifier 

The three octets (i.e. the octet number 4, 5, and 6) that follow the Reason field contain the Call-Identifier field. The 
Call-Identifier field uniquely specify the II session across all II interfaces (i.e. between the ICS AS and all ICS UEs 
connected to the ICS AS). The Call-Identifier field is divided into two subfields, i.e. the part-1 subfield consisting of 
one octet and the part-2 subfield consisting of two octets. The part 1 subfield is always filled by the UE, while the part-2 
subfield is always filled by the ICS AS. The part-1 and part-2 subfields are analogous to the SIP tags inserted in the 
From and To header fields. The values of all "0" inserted in the octet 3 (i.e. in the Call-Identifier Part-1) indicates that 
the Call-Identifier (Part-1) subfield is empty (i.e. it has no value). Likewise, values of all "0" inserted in the octet 4 
and 5 (i.e., in the Call-Identifier Part-2) indicates that the Call-Identifier Part-2 subfield is empty (i.e., it has no value). 
When the UE forwards the first II message pertaining to an II session that is being established (e.g., an II Invite or an 
II Progress) to the ICS AS, the UE inserts a new value into the Call-Identifier (Part-1) subfield (i.e., a value that is 
currently not being unused). Likewise, when the ICS AS forwards the first II message pertaining to an II session that is 
being established (e.g., an II Invite or an II Progress) to the UE, the ICS AS inserts a value into the part-2 subfield. 
When inserting a value into the Call-Identifier (Part-2) subfield, the ICS AS has to insure that the resulting Call- 
Identifier field is unique across all II interfaces. For example, the ICS AS, upon receiving the first II message from the 
ICS UE, may insert into the Call-Identifier (Part-2) subfield a value that it is currently using in some other II sessions, 
only if the resulting Call-Identifier field is unique across all II interfaces (i.e. between the ICS AS and all ICS UEs). 

Some values inserted into the Call-Identifier (Part-1 and Part-2) field are reserved. The Call-Identifier (Part-1 and Part- 
2) subfield with all bits set to values "1" is a reserved and it is used to identify the II session that was automatically 
bound to a CS bearer that was previously set up without using the II protocol. For example, a single CS call that was 
established using SRVCC may be automatically bound to the II session identified with the Call-Identifier (Part-1 and 
Part-2) subfield with all bits set to values "1" without the ICS UE and the SCC AS exchanging the II session 
establishing messages. The usage of the reserved Call-Identifier values is specified in the respective clauses in this 
document. 

7.2.2.1.5 Sequence-ID 

The Sequence-ID field value (i.e., the octet number 7) guarantees the proper ordering of the II message. The sender of 
the II message increments the Message sequence number value by one for each new II message forwarded to its peer. 
The sequence number value is expressible as an 8-bit unsigned integer. Once the count reaches the value of 2**8, it 
wraps around back to one. 

7.3 Messages 

7.3.1 General Messages 

Table 7.3.1 lists the Ilmessages and their encoding. The prefix "Ox" indicates that what follows is a bit stream 
represented as a hexadecimal number. 
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Table 7.3.1 : General Message types 



Message 


Message Type value (5 bit) 


Reason value (10 bit) 


11 Invite (MO) 


0x1 


0x000 


11 Invite (MI) 


0x1 


0x001 


11 Invite 
(Augmentation) 


0x1 


0x002 


11 Invite (use 
existing CS 
bearer) 


0x1 


0x003 


11 Invite (CW) 


0x1 


0x005 


11 Bye 


0x2 


0x000 


11 Notify 
(used for 
synchronization) 


0x3 


0x001 


11 Notify 


0x3 


0x002 - 0x64 


11 Refer 


0x9 


0x000 


11 Progress 


0x00 


0x64 - 0xC7 (NOTE 1) 


11 Success 


0x00 


0xC8-0x12B 


11 Mid Call 

Request 

message 


0x4 


0x001 


11 Failure 


0x00 


0x12C-0x25E(NOTE2) 


11 Dummy 


0x00 


0x3FF 


NOTE 1 : The value in the Reason field corresponds to the hex-encoded SIP Ixx 

values, as specified in subclause 21 .1 of RFC 3261 [6]. 
NOTE 2: The value in the Reason field corresponds to the hex-encoded SIP 4xx, 
5xx, and 6xx values, as specified in subclauses 21 .4, 21 .5, and 25.6 of RFC 3261 [6]. 



7.3.2 11 INVITE - ICS UE initiated 
7.3.2.1 General 

This message is sent by the ICE UE to the network to establishment of a session. See table 7.3.2.1. 
Message type: II INVITE 
Direction: ICS UE to SCC AS 
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Table 7.3.2.1 : II INVITE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - INVITE 
7.2.2.2.1.2 


M 


V 


2 


Call ID 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence-Id 
7.2.2.1.5 


M 


V 


1 


Timestamp 


Timestamp 
7.3.2.8 





TLV 


1 


To-id 


To-id 
7.3.2.3 


M 


TLV 


3-X 

Note 1 


From-id 


From-id 
7.3.2.4 


M 


TLV 


3-X 

Note 1 


Accept Contact 


Accept Contact 
7.3.2.5 





TLV 


5 


ERAccept Contact 


ERAccept Contact 
7.3.2.6 





TLV 


3-X 

Note 1 


Reject Contact Reject Contact TLV 5 

7.3.2.7 
Note 1 - The length of this information element in combination with the other information elements 
cannot exceed the length of the transport protocol information element to transport the 11 message. 



7.3.2.2 



Message Type 



Identifies that the message is: 

i) a Mobile Originated II INVITE. 



7.3.2.3 



To-id 



This information element shall be included, it identifies the logical identity of the recipient for the request according to 
the procedures specified in RFC 3261 [6]. For the coding of this information element please see subclause 7.4.2. 3A. 



7.3.2.4 



From-id 



This information element shall be included, it identifies the logical identity that the dialogue originates from according 
to the procedures specified in RFC 3261 [6]. For the coding of this information element please see subclause 7.4.2.3. 

7.3.2.5 Accept Contact 

This information element shall be optionally included, if feature tags are indicated. 

7.3.2.6 ERAccept Contact 

This information element shall be optionally included, if feature tags that have been qualified with the parameter tag 
"explicit" or "require" are indicated. 

7.3.2.7 Reject Contact 

This information element shall be optionally included, if feature tags are indicated. 

7.3.2.8 Timestamp 

This information element shall be included if using a transport layer protocol that is not a real-time transport layer 
protocol; it provides the SCC AS local time to the ICS UE. 



£75/ 



3GPP TS 24.294 version 9.5.0 Release 9 



49 



ETSI TS 124 294 V9.5.0 (2011-04) 



7.3.3 INVITE - sec AS initiated 
7.3.3.1 General 

This message is sent by the SCC AS to the ICS UE to establishment of a session. See table 7.3.3.1. 
Message type: II INVITE. 
Direction: SCC AS to ICS UE 

Table 7.3.3.1 : II INVITE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 
7.2.2.1.2 


M 


V 


1 


Message Type 


Request Message - INVITE 
7.2.2.2.2.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence- Id 
7.2.2.1.5 


M 


V 


1 


Timestamp 


Timestamp 
7.3.3.6 





TLV 


1 


From-id 


From-id 
7.3.3.3 


M 


TLV 


3-X 
Note 1 


SCC AS PSI DN 


SCC AS PSI DN 
7.3.3.5 


M 


LV 


3-15 


To-id 


To-id 
7.3.3.4 


M 


TLV 


3-X 

Note 1 


Conference-id 

Note 1 - The length of this infc 
cannot exceed the length of th 


Conference-id 

7.4.2.16 

jrmation element in combinat 

e transport protocol informatic 




on with the othe 
DR element to tr; 


LV FFS 

r information elements 
insporttheH message. 



7.3.3.2 



Message Type 



Identifies that the message is: 

i) a Mobile Terminated II INVITE. 



7.3.3.3 



From-id 



This information element shall be included; it identifies the logical identity that the dialogue originates from. It is the 
same as that defined in RFC 3261 [6] however no display name is included. For the coding of this information element 
please see subclause 7.4.2.3. 



7.3.3.4 



To-id 



This information element shall be included; it identifies the logical identity of the recipient for the request. It is the same 
as that defined in RFC 3261 [6]. For the coding of this information element please see subclause 7.4. 2. 3 A. 



7.3.3.5 



SCC AS PSI DN 



This information element, as specified in subclause 7.4.2.5, shall be included; it uniquely identifies the SCC AS and 
session on that AS. 



7.3.3.6 



Timestamp 



This information element,as specified in subclause 7.4.2.14, shall be included if using a transport layer protocol that is 
not a real-time transport layer protocol, it provides the SCC AS local time to the ICS UE. 
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7.3.3.7 



Conference-id 



This information element, as specified in subclause 7.4.2.16, is included when the SCC AS invites an ICS UE to join a 
conference. 

7.3.4 BYE - ICS UE initiated 
7.3.4.1 General 

This message is sent by the ICS UE to the SCC AS to establishment of a session. See table 7.3.4.1. 
Message type: II BYE 
Direction: ICS UE to SCC AS 

Table 7.3.4.1 : II BYE message content 



Information 
element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 
7.2.2.1.2 


M 


V 


1 


Message Type 


Request Message - BYE 
7.3.4.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 



7.3.4.2 Message Type 

Identifies that the message is: 
i) an II BYE. 

7.3.5 BYE - SCC AS initiated 
7.3.5.1 General 

This message is sent by the SCC AS to the ICS UE to establish of a session. See table 7.3.5.1. 
Message type: II BYE 
Direction: SCC AS to ICS UE 

Table 7.3.5.1 : II BYE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 
7.2.2.1.2 


M 


V 


1 


Message Type 


Request Message - BYE 
7.3.5.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 



7.3.5.2 



Message Type 



Identifies that the message is: 
i) an II BYE. 
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7.3.6 11 PROGRESS - ICS UE initiated 



7.3.6.1 General 

This message is sent by the ICE UE to the network to establish of a session. See table 7.3.6. 1. 
Message type: II PROGRESS 
Direction: ICS UE to SCC AS 

Table 7.3.6.1 : II PROGRESS message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - PROGRESS 
7.3.6.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence- Id 
7.2.2.1.5 


M 


V 


1 



7.3.6.2 



Message Type 



Identifies that the message is 
i) an II PROGRESS. 

7.3.7 II PROGRESS - SCC AS initiated 
7.3.7.1 General 

This message is sent by the SCC AS to the ICS UE to establish of a session. See table 7.3.3.1. 
Message type: II PROGRESS 
Direction: SCC AS to ICS UE 

Table 7.3.3.1 : II PROGRESS message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - PROGRESS 
7.3.7.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence-Id 
7.2.2.1.5 


M 


V 


1 


SCC AS PSI DN 


SCC AS PSI DN 
7.3.7.3 


M 


LV 


3-15 



7.3.7.2 



Message Type 



Identifies that the message is: 
i) an II PROGRESS. 
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7.3.7.3 



sec AS PSI DN 



This information element, as specified in subclause 7.4.2.5, shall be included; it uniquely identifies the SCC AS and 
session on that AS. 

7.3.8 11 FAILURE 



7.3.8.1 



General 



This message is sent by the ICE UE to the network or from the network to the ICS UE to identify that an error has 
occured. See table 7.3.8.1. 

Message type: II Failure 

Direction: ICS UE to SCC AS and SCC AS to ICS UE 

Table 7.3.8.1 : II Failure message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - INVITE 
7.3.8.2 


M 


V 


2 


Call ID 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence-Id 
7.2.2.1.5 


M 


V 


1 


To-id 


To-id 
7.3.8.3 





TLV 


3-X 

Note 1 


Reason Phrase 

Note 1 - The length of the To- 
elements cannot exceed the k 
message. 


Phrase 

7.3.8.4 

id information element in comb 

jngth of the transport protocol 




ination with the 
nformation elerr 


TLV 

other inform 
lent to transp 


ation 
)onthe 11 



7.3.8.2 Message Type 

Identifies that the message is: 
i) an II FAILURE. 



7.3.8.3 



To-id 



This information element, as specified in subclause 7.4.2.3, may optionally be included and can appear multiple times. 
It identifies alternative address's that the UE should attempt to use It is the same as the contact header field that is 
defined in sections 21.3 of RFC 3261 [6]. 



7.3.8.4 



Reason Phrase 



This information element, as specified in subclause 7.4.2.13, may optionally be included and can appear multiple time. 
It is the same as the Reason-Phrase header field that is defined in RFC 3261 [6]. 



7.4 



II information elements and functional definition 



7.4.1 II information elements 

The list of the II information elements is shown in table 7.4.1. 



£75/ 



3GPP TS 24.294 version 9.5.0 Release 9 



53 



ETSI TS 124 294 V9.5.0 (2011-04) 



Table 7.4.1 11 -information elements 



11 information eiement 
Name 


Description and 

content 

(subclauses) 


Error-code 


7.4.2.2 


From-id 


7.4.2.3 


To-id 


7.4.2.3A 


Privacy 


7.4.2.4 


SCC-AS-id 


7.4.2.5 


Session-identifier 


7.4.2.6 


Replaces 


7.4.2.8 


Accept Contact 


7.3.2.9 


ERAccept Contact 


7.3.2.10 


Reject Contact 


7.3.2.11 


Mid-Call 


7.4.2.12 


Reason Phrase 


7.4.2.13 


Timestamp 


7.4.2.14 


Refer- to 


7.4.2.15 


Conference-id 


7.4.2.16 



Error-code 

The Error-code information element is included in every Il-Error response message. The Error-code information 
element is binary encoded SIP failure response. The SIP 4xx request failure responses, the 5xx server failure responses, 
and the 6xx global failure responses are binary encoded and included in the Error-code information element as specified 
in subclause 7.4.2.1 and table 7.4.2.1. The interpretation of each binary encoded failure response is analogous to the 
interpretation of associated SIP failure response. 

From-id Information 

The From-id Information IE specifies a public user identity of the calling user, e.g., the calling party number, either as 
an E.164, Identifier or a SIP URL 

The From-id information element may contain either an E. 164, a SIP URI or a identifier that identifies a public user 
identity to be used (see annex A). 

To-id Information 

The To-id Information IE specifies a public user identity of the called user, e.g., the called party number. 

The To-id information element may contain either an E.164, a SIP URI or a identifier that identifies a public user 
identity to be used (see annex A). 

Privacy 

The UE uses the Privacy information element to indicate to the SCC AS how to handle the SIP header fields when the 
sec AS forwards the SIP requests and responses on behalf of the UE to the far-end UA. The Privacy information 
element when sent by the UE to the SCC AS contains binary encoded "priv-value" (as specified in the RFC 3323 [8] 
and RFC 3325 [9]). When the SCC AS, upon receiving a Privacy information element over II interface, forwards a SIP 
request or a response to the far-end UA, the SCC AS behaves as specified in the RFC 3323 [8] and RFC 3325 [9] e.g. 
the SCC AS inserts a P-Asserted-Identity header field into SIP message as requested by the Privacy information 
element. 

SCC-AS-id 

The SCC-AS-id information element contains an International E.164 number representation of the SCC AS PSI DN that 
points to the SCC AS. When the UE sets up a CS bearer connection by sending a SETUP message to the MSC server, 
the UE specifies the respective International E. 164 number as the called party number. Subsequently the call will be 
routed to the respective SCC AS via a MGCF where the SCC-AS-PSI-DN will be treated as a wildcard PSI as specified 
in 3GPP TS 23.003 [15] and procedures as specified in 3GPP TS 24.229 [12] subclause 5.3,2.1 item 3. 

Session-identifier 
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The Session-identifier information element is an identifier used either by the UE or the SCC AS to uniquely and 
globally identify a II session across all interface (i.e. the II interface, Gm interface and the IMS). The Session identifier 
is dynamically allocated by the SCC AS to identify the II session that is being established. The SCC AS includes the 
Session-identifier information element in the first II message sent by the SCC AS to the UE. The Session-identifier 
information element may contain different values, e.g. the Session Transfer Identifier (STI), as specified in 
subclause 7.4.2.1 and associated subclause 7.4.2.1. 

Replaces 

The Replaces information element is used by the UE to identify an existing call or a SIP dialog that will be replaced 
with an II session being established over the II interface. When the UE wants to replace an existing call or a SIP dialog 
with a new II session, the UE sends an II Invite request message to the SCC AS with the Replaces information element 
that contains the identity of the SIP dialog or a call that will be replaced with a new call being established. In the case of 
UE assisted T-ADS, the SCC AS may send an II Invite request message to the terminating ICS UE with Replaces 
information element that contains the identity of the SIP dialog to change the service control for the session from Gm to 
II. 

Accept Contact 

The Accept contact information element is used by the UE to identify the SIP feature tags that the UE are included in a 
SIP Accept Contact header per procedures in RFC 3841 [14]. However if the feature tags are to be appended with 
"explicit" and or the "require" parameter tags then the SIP feature tag shall not be sent in the Accept Contact but in the 
ERAccept Contact header information element. 

ERAccept Contact 

The ERAccept contact information element is used by the UE to identify those SIP feature tags that either "explicit" or 
"require" parameter tags added per procedures in RFC 3841 [14]. If "explicit" and or "require" parameter tag is required 
then the feature tag is not included in the Accept Contact information element. 

Reject Contact 

The Reject contact information element is used by the UE to identify the SIP feature tags that the UE would normally 
send in a SIP Reject contact header per procedures in RFC 3841 [14]. 

Mid-Call 

The Mid-Call information element is used between ICS UE and the SCC AS to exchange the Mid-call supplementary 
services control information, e.g. hold, resume, conference. 

Timestamp 

The Timestamp information element specifies a local time on the II message sender. The local time is measured in 
seconds and it is 32 bits long. 

Refer-to 

The II Refer message indicates that the recipient should contact a third party using the contact information provided in 
the Refer-to information element and included in the II Refer message. The third party is identified either with an E.164 
number or a SIP URI and it is included in the Refer-to information element. 

Conference-id 

The Conference-id information element is used by the SCC AS to convey to the ICS UE the identity of the conference 
focus (i.e. SIP URI or an E.I64 number) that will handle the requested conference call. 

Upon a request to create a conference with a conference factory URI, the SCC AS includes in the II Success message 
the Conference-id information element that contains the conference URI (i.e. the E.164 number or a SIP URI of the 
conference focus). The inclusion of the Conference-id information element in the II Success message indicates to the 
ICS UE that the requested conference has been set and the identity of the conference focus that is handling the 
respective conference. 

When the SCC AS invites an ICS UE to join a conference, the SCC AS sends an II Invite message to the invited ICS 
UE that includes the Conference-id information element. The inclusion of the Conference-id information element in the 
II Invite message indicates to the ICS UE that it has been invited to join a conference and the identity of the conference 
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focus that is handling the respective conference. Subsequently, this ICS UE may use the received Conference-id 
information element to e.g. leave the indicated conference, invite another ICS UE to the indicated conference, etc. 

7.4.2 11 Information elements encoding 
7.4.2.1 General 

The structure of the II information elements is shown in figure 7.4.2.1. 



8 


1 7 1 6 1 5 1 4 


3 2 1 


Octet 


Information Element code 


Code specific 


1 


Information Element length (in octets) 


2 


Information Element body (as required) 


3 


etc. 





Figure 7.4.2.1 : II information element format 

Each II information element contains a common two-octet field followed by a variable-size body. The first octet 
contains the Information Element code and Code specific values. Each II information element is uniquely identified 
with the respective Information Element code (i.e., encoded with bits numbered 4, 5, to 8 of the first octet). The Code 
specific value (i.e., encoded with bits numbered 1, 2, and 3 of the first octet) provide additional information about 
respective II information element. For example, if the Information Element code specifies that this is a To-id II 
information element, then the Code specific value will indicate whether the Information Element body contains an 
E.164 number or SIP URI. The Code specific values for each respective II information element are described in the 
respective subclauses. 

The second octet i.e. the Information Element length specifies the length of the II information element body (i.e., the 
number of octets following the Information Element length) in binary format. The bit number 1 of octet number 2 is the 
list significant bit and bit number 8 of the octet number 2 is the most significant bit. The table 7.4.2.1 specifies the 
Information Element code for each II information element. 



Table 7.4.2.1 : II -information element coding 



Information 
Element code 


11 information element 
Name 


Reference 
subclause 


Bits 
87654 






10011 


From-id 


7.4.2.3 


10 100 


Privacy 


7.4.2.4 


10 10 1 


SCC-AS-id 


7.4.2.5 


10 110 


Session-identifier 


7.4.2.6 


10010 


Replaces 


7.4.2.8 


10111 


Accept Contact 


7.4.2.9 


10001 


ERAccept Contact 


7.4.2.10 


110 11 


Reject Contact 


7.4.2.11 


11000 


Mid-Call 


7.4.2.12 


11100 


Keason-Phrase 


7.4.2.13 


11001 


Timestamp 


7.4.2.14 


11100 


To-id 


7.4.2.3A 


11101 


Refer-to 


7.4.2.15 


11110 


Conference-id 


7.4.2.16 



7.4.2.2 



Void 



7.4.2.3 



From-id Information 



The purpose of the From-id information element is to transport a public identity of the From Party. The From-id 
information element may contain either a SIP URI or a telephone number (e.g. international number, national number) 
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or an identifier value that identifies a known public identity. The Code specific field as specified in table 7.4.2.3.1, i.e., 
the bits 3, 2, and 1 of the octet number 1 specify the type of information contained in the From-id information element. 

If the From-id Information is a SIP URI username@domainname then the Code specific field as specified in table 
7.4.2.3.1 bits 3,2, and 1 shall be set to "010" and shall be encoded to an octet string according to UTF-8 encoding rules 
as specified in RFC 3629 [16]. 

When bits 3, 2, and 1 of the octet number 1 are to be set to "001" to indicate that the From-id information element 
contains an E. 164 number (see table 7.4.2.3.1). This is deduced when the From-id Information to be used by is a tel URI 
or a SIP URI with URI parameter User=Phone then the Code specific field and if a tel or SIP URI is identified as being 
globally unique identified by the presence of "+" character at the start of the digit string. 

When bits 3, 2, and 1 of the octet number 1 are to be set to "000" it indicates that the From-id information element 
contains a number whose type of number is unspecified (see table 7.4.2.3.1) e.g. local or national number. This is 
deduced when the Identity Information to be used by is a tel URI or a SIP URI with URI parameter User=Phone and if a 
tel or SIP URI is not identified as being globally unique identified by the presence of "+" character at the start of the 
digit string. 

When bits 3, 2, and 1 of the octet number 1 are to be set to "000" it indicates that the From-id information element 
contains a public user identity that is an identifier and can be can be derived (see annex A). 

When the From-id information element contains an International number (i.e. an E. 164 number), the E.164 digit-string 
is included in the octet 3, octet 4, octet 5, etc. as follows: 

the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the E.164 
digit-string; 

the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the E. 164 
digit-string; 

the bits numbers 8, 7, 6, and 5 of octet number 4 are used binary encode the next significant digit of the E.164 
digit-string; and so on until the entire E.164 digit-string is included in the From-id information element; and 

the bit-pattern "11 IT'iserted either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicates the end of 
the E. 1 64 digit-string, i.e. the bit-pattern of " 1 1 11 " is used as the end-delimiter for the E. 1 64 digit-string. 

When the From-id information element contains an local or national number, the digit-string is included in the octet 3, 
octet 4, octet 5, etc. as follows: 

the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the digit- 
string; 

the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the digit- 
string; 

the bits numbers 8, 7, 6, and 5 of octet number 4 are used binary encode the next significant digit of the digit- 
string; and so on until the entire digit-string is included in the From-id information element; and 

the bit-pattern "11 IT'iserted either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicates the end of 
the digit-string, i.e. the bit-pattern of "1 1 1 1" is used as the end-delimiter for the digit-string. 



Octet 

1 

2 
3-Y 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
11 


Code specific 


Information Element length (in octets) 


Information Element body 



Figure 7.4.2.3.1-1: From-id information element 
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Table 7.4.2.3.1 : From-id information element 



(octet 1) 


Code specific 


Bits 1 


32 1 




000 


Unspecified 


00 1 


International number, i.e. E.I 64 number (Note 1) 


01 


SIPURI 


01 1 


Identifier (See Annex A) 




Other values are reserved for future use 


(octet 3) 


SIPURI 




The URI shall be encoded to an octet string according to UTF-8 encoding rules as specified in 
RFC 3629 [16] 


(octet 3) 


Identifier 


Contains one octet body coded with identifier value that identifies the public user identity. 


(octet 3) 


Bits 


8765 


the most significant digit of the E. 1 64 digit-string 


(octet 3) 


Bits 


4321 


the next significant digit of the E.I 64 digit-string (Note 2) 


(octet 4) 


Bits 


8765 


the next significant digit of the E.I 64 digit-string (Note 2) 


(octet 4) 


Bits 


4321 


the next significant digit of the E.I 64 digit-string (Note 2) 


(next octet) 


Bits 


(Note 2) 1 


(Note 3) 


Note 1 - Prefix or escape digits shall not be included. 

Note 2 -the next significant digits of the E.I 64 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2. 
Note 3 -The E.I 64 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any 
octet indicating the end of the E.I 64 digit-string. 



7.4.2.3A 



To-id Information 



The purpose of the To-id information element is to transport a public identity of the To Party. The To-id information 
element may contain either a SIP URI or a telephone number (e.g. international number, national number) or an 
identifier value that identifies a known public identity. The Code specific field, i.e., the bits 3, 2, and 1 of the octet 
number 1 specify the type of information contained in the To-id information element,. 

If the To-id Information is a SIP URI username@domainname then the Code specific fields bits 3,2, and 1 shall be set 
to "010" and shall be encoded to an octet string according to UTF-8 encoding rules as specified in RFC 3629 [16]. 

When bits 3, 2, and 1 of the octet number 1 are to be set to "001" it indicates that the To-id information element 
contains an E.164 number (see table 7.4.2.3.1-2). This is deduced when the To-id to be used by is a tel URI or a SIP 
URI with URI parameter User=Phone then the Code specific field and if a tel or SIP URI is identified as being globally 
unique identified by the presence of "+" character at the start of the digit string. 

When bits 3, 2, and 1 of the octet number 1 are to be set to "000" it indicates that the To-id information element 
contains a number whose type of number is unspecified(see table 7.4.2.3.1-2) e.g. local or national number. This is 
deduced when the To-id to be used by is a tel URI or a SIP URI with URI parameter User=Phone and if a tel or SIP 
URI is not identified as being globally unique identified by the presence of "+" character at the start of the digit string. 

When bits 3, 2, and 1 of the octet number 1 are to be set to "000" it indicates that the To-id information element 
contains a public user identity that is an identifier and can be can be derived (see annex A). 

When the To-id information element contains an International number (i.e. an E.164 number), the E.164 digit-string is 
included in the octet 3, octet 4, octet 5, etc. as follows: 
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the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the E.164 
digit-string; 

the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the E.164 
digit-string; 

the bits numbers 8, 7, 6, and 5 of octet number 4 are used binary encode the next significant digit of the E.164 
digit-string; and so on until the entire E.164 digit-string is included in the From-id information element; and 

the bit-pattern "11 IT'iserted either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicates the end of 
the E. 1 64 digit-string, i.e. the bit-pattern of " 1 1 11 " is used as the end-delimiter for the E. 1 64 digit-string. 

When the To-id information element contains an local or national number, the digit-string is included in the octet 3, 
octet 4, octet 5, etc. as follows: 

the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the digit- 
string; 

the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the digit- 
string; 

the bits numbers 8, 7, 6, and 5 of octet number 4 are used binary encode the next significant digit of the digit- 
string; and so on until the entire digit-string is included in the From-id information element; and 

the bit-pattern "11 IT'iserted either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicates the end of 
the digit-string, i.e. the bit-pattern of "1 1 11" is used as the end-delimiter for the digit-string. 

Table 7.4.2.3A.1-1 : To-id information element 



8 


7 6 5 4 


3 2 1 


Octet 


1 


Information Element code 

110 


Code specific 


1 


Information Element length (in octets) 


2 


Information Element body 


3 


etc. 
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Table 7.4.2.3A.1-2: To-id information element 



(octet 1) 
Bits 
32 1 
000 
001 
01 
01 1 

(octet 3) 
SIPURI 



(octet 3) 
Identifier 

(octets) 

Bits 

8 765 
(octet 3) 

Bits 

4321 
(octet 4) 

Bits 

8 765 
(octet 4) 

Bits 

4321 
(next octet) 

Bits 



Code specific 



Unspecified 

International number, i.e. E.I 64 number (Note 1) 

SIPURI 

Identifier (See Annex A) 

Other values are reserved for future use 



The URI shall be encoded to an octet string according to UTF-8 encoding rules as specified in 
RFC 3629 [1 6] 



Contains one octet body coded with identifier value that identifies the public user identity. 



the most significant digit of the E. 1 64 digit-string 



the next significant digit of the E.I 64 digit-string (Note 2) 



the next significant digit of the E.I 64 digit-string (Note 2) 



the next significant digit of the E.I 64 digit-string (Note 2) 



(Note 3) 



(Note 2) 



Note 1 : Prefix or escape digits shall not be included. 

Note 2: The next significant digits of the E.I 64 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 

2. 
Note 3: The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any 
octet indicating the end of the E.164 digit-string. 



7.4.2.4 



Privacy 



The ICS UE may include the Privacy information element in the II Invite message to indicate its privacy preferences 
that the SCC AS should apply to the SIP session toward the remote UE. When the SCC AS sets up a SIP session on 
behalf of the UE, the SCC AS sends a SIP INVITE request that includes the privacy information that the SCC AS 
received in the Privacy information element. 

The Privacy information element when sent by the ICS UE to the SCC AS contains binary encoded "priv-value" (with 
the same semantics as specified in the RFC 3323 [8] and RFC 3325 [9]). The UE may request multiple types of privacy 
for the same call (see RFC 3323 [8]). Hence, the UE include all of the requested privacy types in its Privacy information 
element by setting the respective bits as shown in table 7.4.2.4. 1 . 

Octet 

1 

2 
3 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
10 


Code specific 


Information Element length (in octets) 


Information Element body 



Figure 7.4.2.4.1 : Privacy information element 
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Table 7.4.2.4.1 : Privacy information element 



(octet 1) 


Code specific 


Bits 




32 1 




001 


(NOTE 1) 




Other values are reserved for future use 


(octets) 




Bits 




1 


The UE indicates to the SCCAS that "Privacy: id" (as specified in the RFC 3325 [9]) is requested 




(NOTE 2). 


Bit? 




1 


The UE indicates to the SCCAS that "Privacy: header" (as specified in the RFC 3323 [8]) is 




requested (NOTE 2) 


Bite 




1 


The UE indicates to the SCCAS that "Privacy: session" (as specified in the RFC 3323 [8]) is 




requested (NOTE 2) 


Bits 




1 


The UE indicates to the SCCAS that "Privacy: user" (as specified in the RFC 3323 [8]) is requested 




(NOTE 2) 


Bit 4 




1 


The UE indicates to the SCCAS that "Privacy: none" (as specified in the RFC 3323 [8]) is 




requested (NOTE 2) 


Bits 




1 


The UE indicates to the SCCAS that "Privacy: critical" (as specified in the RFC 3323 [8]) is 




requested (NOTE 2) 


Bits 2 and 1 reserved for future use 


NOTE 1 : If 


the Code specific value is set to "001" it indicates that the Privacy information element consists of three 


octets and each bit in octet number 3 is interpreted as specified in this table. 


NOTE 2: The value of "0" in this bit indicates that corresponding "priv-value' (with the same semantics as specified in 


the RFC SS23 [S] and RFC 3325 [9]) is not used and respective privacy is not requested. 



7.4.2.5 



SCC-AS-id 



The SCC-AS-id information element contains an International E. 164 Number representation of the SCC AS PSI DN 
that points to the SCC AS. The SCC AS PSI DN information element has a minimum length of 3 octets and a maximum 
length of 10 octets. 

The SCC-AS-id information element may contain either a SIP URI or an international telephone number (i.e. an E. 164 
national number). The Code specific field as specified in table 7.4.2.5.1, the bits 3, 2, and 1 of the octet number 1 
specify the type of information that is used to identify the SCC AS. When the SCC AS forwards a SCC AS PSI DN 
associated with the SCC AS to the UE, the SCC AS will include the SCC AS PSI DN in the SCC-AS-id information 
element. The PSI DN is an E.164 number. 

When the Code specific field as specified in table 7.4.2.5.1, bits 3, 2, and 1 of the octet number 1 shall be set to "001" it 
indicates that the SCC-AS-id information element contains a SCC AS PSI DN (i.e. an E.164 number). When the SCC- 
AS-id information element contains a PSI DN (i.e. an E.164 number), the E.164 digit-string is included in the octet 3, 
octet 4, octet 5, etc. as shown in table 7.4.2.5.1. 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
10 1 


Code specific 


Information Element length (in octets) 


Information Element body 



Octet 

1 

2 
4 



Figure 7.4.2.5.1 : SCC-AS-id information element 
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Table 7.4.2.5.1 : SCC-AS-id information element 



(octet 1) 
Bits 
321 
000 
001 


Code specific 

Unspecified 

PSI DM, i.e. E.164 number (Note 1) 

Other values are reserved for future use 








(octets) 
Bits 
8765 


the most significant digit of the E.164 digit-string 








(octet 3) 
Bits 
4321 


the next significant digit of the E.1 64 digit-string 


(Note 2) 






(octet 4) 
Bits 
8765 


the next significant digit of the E.1 64 digit-string 


(Note 2) 






(octet 4) 

Bits 

4 3 2 1 the next significant digit of tlie E.1 64 digit-string (Note 2) 
(next octet) 

Bits 

(Note 3) 
Note 1 - Prefix or escape digits sliall not be included. 

Note 2 -the next significant digits of the E.I 64 digit-string are included in subsequent bits 8, 7, 6 
Note 3 -The E.I 64 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 
octet indicating the end of the E.I 64 digit-string. 


and 5 or bits 4, 3, 2. 
3, 2, and 1 of any 



7.4.2.6 Session-identifier 

The Session-identifier information element is used either by the ICS UE or the SCC AS to covey the identity of the 
session being established. The Code specific subfield, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of 
information that is used to identify the session across. 

When a SIP dialog or an II session is identified with an E.164 number (e.g. with a STI), then this identifier is conveyed 
across the II interface in a Session-identifier information element. In this case, the Code specific field, i.e., the bits 3, 2, 
and 1 of the octet number 1 is set to "001", as shown in figure 7.4.2.6.1 and table 7.4.2.6.1. 



Octet 

1 

2 
3 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
110 


Code specific 


Information Element length (in octets) 


Information Element body 



Figure 7.4.2.6.1 : Session-identifier information element 
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Table 7.4.2.6.1 : Session-identifier information element 



(octet 1) Code specific 

Bits 
321 



Unspecified 

1 Session or a dialog identified witli an E.164 number (Note 1) 

Other values are reserved for future use 



(octets) 
Bits 
8 7 6 5 the most significant digit of tfie E.164 digit-string 



(octet 3) 
Bits 
4 3 2 1 the next significant digit of the E.I 64 digit-string (Note 2) 



(octet 4) 
Bits 
8 7 6 5 the next significant digit of the E.1 64 digit-string (Note 2) 



(octet 4) 

Bits 

4 3 2 1 the next significant digit of the E.1 64 digit-string (Note 2) 

(next octet) 

Bits 

(Note 3) 
Note 1 - Prefix or escape digits shall not be included. 

Note 2 -the next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2. 
Note 3 -The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any 
octet indicating the end of the E.164 digit-string. 



7.4.2.7 Void 

7.4.2.8 Replaces 

The Replaces information element is included in the II Invite message to indicate to the recipient that the II session 
being established will replace the existing SIP dialog identified by the Replaces information element. The Replaces 
information element also contains the identity of the dialog that will be replaced. 

8 7 6 5 4 3 2 1 Octet 

1 



Information Element code 
10 10 


Code specific 


Information Element length (in octets) 











2 
3 

, 4 

Figure 7.4.2.8.1 : Replaces information element 
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Table 7.4.2.8.1 : Replaces information element 



(octet 1 ) 
Bits 


Code specific 


32 1 




000 
001 


Unspecified 

The Code specific value set to "001" Specifies that the SIP dialog that will be replaced is identified 

with a ST! that is an E.I 64 number. (NOTE 1) 




Other values are reserved for future use 


(octet 3) 
Bits 




8765 


the most significant digit of the E.I 64 digit-string 


(octet3) 
Bits 




4321 


the next significant digit of the E.I 64 digit-string (NOTE 2) 


(octet 4) 
Bits 




8765 


the next significant digit of the E.I 64 digit-string (NOTE 2) 


(octet 4) 
Bits 




4321 
(next octet) 
Bits 


the next significant digit of the E. 1 64 digit-string (NOTE 2) 


(NOTE 3) 
NOTE 1 : Prefix or escape digits shall not be included. 

NOTE 2: The next significant digits of the E.I 64 digit-string are included in subsequent bits 8, 7, 6, and 5 or 
bits 4, 3, 2. 


NOTE 3: The E.I 64 digit-string terminates with delimiter "1111 " either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of 


any octet, hence 


indicating the end of the E.I 64 digit-string. 



7.4.2.9 Accept Contact 

The UE may include the Accept Contact element in the II Invite message to indicate any called feature preferences per 
RFC 3841 [14]. The Code Specific value the bits 3, 2, and 1 of the octet number 1 is set to "001" as specified in 
table 7.4.2.9. 
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8 


7 6 5 4 


3 2 1 


1 


Information Element code 
11 


Code specific 


Information Element length (in octets) 


Information Element body 



Octet 

1 

2 
3 Y 



Figure 7.4.2.9: Accept Contact information element 
Table 7.4.2.9: Accept Contact information element 



(octet 1 ) 
Bits 
321 
000 
001 


Code specific 

Unspecified 

Accept Contact 

All other values reserved 


(octets) 


Bit Specific 


Bits 1 


1 


sip.audio as defined in RFC 3840 [15] 


2 


sip.application as defined in RFC 3840 [15] 


3 


sip.data as defined in RFC 3840 [15] 


4 


sip.control as defined in RFC 3840 [15] 


5 


sip.video as defined in RFC 3840 [15] 


6 


sip.text as defined in RFC 3840 [15] 


7 


sip.automata as defined in RFC 3840 [15] 


8 


sip.duplex = full as defined in RFC 3840 [15] 



(octet 4) Bit Specific 


Bits 


1 


sip.duplex = half, as defined in RFC 3840 [15] 


2 


sip.duplex = receive only as defined in RFC 3840 [15] 


3 


sip.duplex = send only as defined in RFC 3840 [15] 


4 


sip. mobility = fixed as defined in RFC 3840 [15] 


5 


sip. mobility = mobile as defined in RFC 3840 [15] 


6 


sip.actor =principal, as defined in RFC 3840 [15] 


7 


sip.actor =attendant, as defined in RFC 3840 [1 5] 


8 


sip.actor = msg-taker, as defined in RFC 3840 [15] 



(octet 5) Bit Specific 


Bits 


1 


sip.actor- information as defined in RFC 3840 [15] 


2 


sip.isfocus as defined in RFC 3840 [15] 


3 


sip.byeless as defined in RFC 3840 [15] 


4 


sip. rendering -yes as defined in RFC 4235 [16] 


5 


sip. rendering - no as defined in RFC 4235 [16] 


6 


sip. rendering - unknown as defined in RFC 4235 [16] 


7 


sip. message as defined in RFC 4569 [17] 


8 


sip. ice 



(octet 6) Bit Specific 


Bits 


1 


Reserved 


2 


Reserved 


3 


Reserved 


4 


Reserved 


5 


Reserved 


6 


Reserved 


7 


Reserved 
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Extension 



7.4.2.1 ERAccept Contact 

The UE may include the ERAccept Contact element in the II Invite message to indicate any called feature preferences 
per RFC 3841 [14] that require the "explicit" and or "require" parameter tag appended to them. The Code Specific value 
the bits 3, 2, and 1 of the octet number 1 is set to "001" as specified in table 7.4.2.10. 

Octet 
1 

2 
3-Y 

Figure 7.4.2.10: ERAccept Contact information element 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
10 


Code specific 


Information Element lengtli (in octets) 


E 


R Feature Tag Value 



Table 7.4.2.10: ERAccept Contact information element 



(octet 1 ) 
Bits 
321 
000 
001 


Code specific 

Unspecified 

ERAccept 

All other values reserved 


(octet 3-Y) 


Feature Tag Value 


Bit 1 


8 


Value 1 "explicit' required as defined in RFC 3841 [14] 


7 


Value 1 "require' required, as defined in RFC 3841 [14] 


6-1 


Feature Tag 



(octet -3-Y) Bit Specific 


Bits 


654321 


000000 


sip.audio as defined in RFC 3840 [15] 


000001 


sip.application as defined in RFC 3840 [15] 


000010 


sip.data as defined in RFC 3840 [15] 


000011 


sip.control as defined in RFC 3840 [15] 


000100 


sip.video as defined in RFC 3840 [15] 


000101 


sip.text as defined in RFC 3840 [1 5] 


000110 


sip.automata as defined in RFC 3840 [15] 


000111 


sip.duplex = full as defined in RFC 3840 [15] 


00 1000 


sip.duplex = half, as defined in RFC 3840 [15] 


00 1001 


sip.duplex = receive only as defined in RFC 3840 [15] 


00 1010 


sip.duplex = send only as defined in RFC 3840 [15] 


00 1011 


sip. mobility = fixed as defined in RFC 3840 [15] 


00 1100 


sip. mobility = mobile as defined in RFC 3840 [15] 


00 1101 


sip.actor = principal, as defined in RFC 3840 [15] 


001110 


sip.actor = attendant, as defined in RFC 3840 [15] 


001111 


sip.actor -= msg-taker, as defined in RFC 3840 [15] 


010000 


sip.actor = information as defined in RFC 3840 [15] 


010001 


sip.isfocus as defined in RFC 3840 [15] 


010010 


sip.byeless as defined in RFC 4235 [16] 


010011 


sip. rendering = yes as defined in RFC 4235 [16] 


010100 


sip. rendering =no as defined in RFC 4235 [1 6] 


010101 


sip. rendering = unknown as defined in RFC 4235 [16] 


010110 


sip. message as defined in RFC 4569 [17] 


010111 


sip. ice 


01 1000 
to 

111111 


Reserved 
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7.4.2.11 Reject Contact 

The UE may include the Reject Contact element in the II Invite message to indicate any called feature preferences per 
RFC 3841 [15]. The Code Specific value the bits 3, 2, and 1 of the octet number 1 is set to "000" as specified in 
table 7.4.2.11. 

Octet 

1 

2 
3-6 

Figure 7.4.2.11 : Reject Contact information element 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
10 


Code specific 


Information Element length (in octets) 


Information Element Body 
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Table 7.4.2.11 : Reject Contact information element 



(octets) Bit Specific 


Bits 


1 


sip.audio as defined in RFC 3840 [15] 


2 


sip.application as defined in RFC 3840 [15] 


3 


sip.data as defined in RFC 3840 [15] 


4 


sip.control as defined in RFC 3840 [15] 


5 


sip.video as defined in RFC 3840 [15] 


6 


sip.text as defined in RFC 3840 [15] 


7 


sip.automata as defined in RFC 3840 [1 5] 


8 


sip.duplex = full as defined in RFC 3840 [1 5] 



(octet 4) Bit Specific 


Bits 


1 


sip.duplex = half, as defined in RFC 3840 [15] 


2 


sip.duplex = receive only as defined in RFC 3840 [15] 


3 


sip.duplex = send only as defined in RFC 3840 [15] 


4 


sip. mobility = fixed as defined in RFC 3840 [15] 


5 


sip. mobility = mobile as defined in RFC 3840 [15] 


6 


sip.actor =principal, as defined in RFC 3840 [15] 


7 


sip.actor =attendant, as defined in RFC 3840 [15] 


8 


sip.actor = msg-taker, as defined in RFC 3840 [15] 



(octet 5) Bit Specific 


Bits 


1 


sip.actor- information as defined in RFC 3840 [15] 


2 


sip.isfocus as defined in RFC 3840 [15] 


3 


sip.byeless as defined in RFC 4235 [16] 


4 


sip. rendering - yes as defined in RFC 4235 [1 6] 


5 


sip. rendering - no as defined in RFC 4235 [16] 


6 


sip. rendering - unknown as defined in RFC 4235 [16] 


7 


sip. message as defined in RFC 4569 [17] 


8 


sip. ice 



(octet 6) Bit Specific 


Bits 


1 


Reserved 


2 


Reserved 


3 


Reserved 


4 


Reserved 


5 


Reserved 


6 


Reserved 


7 


Reserved 


8 


Extension 



7.4.2.12 



Mid-Call 



The Mid-Call information element is used either by the ICS UE or the SCC AS to covey the supplementary services 
control information. The Code specific sub field, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of 
information that is used to identify the services control type. 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
10 


Code specific 


Information Element length (in octets) 


Information Element Body 



Octet 

1 

2 
3 
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Figure 7.4.2.12.1: Mid-Call information element 



Table 7.4.2.12.1: IVIid-Call information element 



(octet 1) 
Bits 
321 
000 
001 
1 
1 1 

N0TE1 

NOTE 2 

NOTE 3 



Code specific 



Unspecified 

Place the call on hold, see subclause 6.3.4 (NOTE 1 , NOTE 2) 

Resume the call, see subclause 6.3.4 (NOTE 1 , NOTE 2) 

Add the third party to an active point-to-point call (NOTE 3) 

Other values are reserved for future use 
When this Code specific value is used, the Information Element body is empty and the Information Element 
length value is set to zero. 

When included by ICS UE, the element indicates that ICS UE puts the call on hold. 
When included by SCC AS, the element indicates that remote UE puts the call on hold. 
If the ICS UE, that has an active end-to-end call with a remote party, wants to add a third party to this end- 
to-end call (i.e. to format three way conference call), the ICS UE will send an II l\/lid Call message to the 
SCC AS that includes an II l\/lid-Call information element as shown in the table 7.4.2.12.2. In the II Mid-Call 
information element, the ICS UE sets the Code specific value to "01 1" and identifies the third party (that will 
be added to the active end-to-end call) with the third party E.I 64 number as shown in the table 7.4.2.12.2. 
The II IVIid call message is sent to the SCC AS over the II session associated with the active end-to-end 
call. In the returned 11 Success message the SCC AS includes the Conference-id information element that 
identifies the conference focus that will handle the resulting conference call. Subsequently, the ICS UE may 
request the conference focus to add additional participants to the conference call. 



Table 7.4.2.12.2: IVIid-Call information element 



(octet I) 



Bits 



87654 



Information Element code 



10110 



Indicates that this is a Mid-call information element 



32 1 



Code specific 



The Code specific values as shown in Table 7.4.2.12.1 



(octet 2) 



Bits 



87654321 



Specify Information Element length (in octets) 



The URI shall be encoded to an octet string according to UTF-8 encoding rules as specified in 
RFC 3629 [16] 



(octet 3) 



Bits 



8765 



the most significant digit of the E.I 64 digit-string (Note 1) 



(octet 3) 



Bits 



4321 



the next significant digit of the E.I 64 digit-string (Note 1 , Note 2) 



(octet 4) 



Bits 



8765 
(octet 4) 



the next significant digit of the E.I 64 digit-string (Note 1 , Note 2) 
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Bits 



4321 



the next significant digit of the E.I 64 digit-string (Note 1 , Note 2) 



(next octet) 



Bits 

(Note 1, Note 2) 



(Note 3) 



Note 1 - Prefix or escape digits shall not be included. 

Note 2 -the next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2, 

and 1. 
Note 3 -The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any 
octet indicating the end of the E.164 digit-string. 



7.4.2.13 Reason-Phrase 

The piupose of the Reason-Phrase field is as defined in RFC 3261 [6]. 

The information element body as specified in table 7.4.2.13.1 shall be encoded to an octet string according to UTF-8 
encoding rules as specified in RFC 3629 [16]. The Code Specific value the bits 3, 2, and 1 of the octet number 1 is set 
to "001" as specified in table 7.4.2.13.1. 

Octet 

1 

2 
3-Y 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
110 


Code specific 


Information Element length (in octets) 


Information Element Body 



Figure 7.4.2.13.1 : Reason-Phrase information element Table 7.4.2.13.1 : Reason-Phrase information 

element 



(octet 1 ) 


Code specific 


Bits 




321 




000 


Unspecified 


001 


Reason Phrase 




All other values reserved 


(octet 3-Y) 






Reason encoded as specified in RFC 3629 [16]. 



7.4.2.14 Time Stamp 

The Timestamp information element is used by the ICS UE and the SCC AS to convey local time. The Timestamp 
information element contains local time measured in seconds. 

When the Code specific field as specified in table 7.4.2.14.1, bits 3, 2, and 1 of the octet number 1 shall be set to "001", 
it indicates that the Timestamp information element contains local time measured in seconds in 32 bits format. The time 
is conveyed across the II interface in a Timestamp information element. 

Octet 

1 

2 
3-6 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
10 1 


Code specific 


Information Element length (in octets) 


Information Element body 



Figure 7.4.2.14.1 : Timestamp information element 
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Table 7.4.2.14.1 : Timestamp information element 



(octet 1) Code specific 

Bits 
32 1 

Unspecified 

00 1 Timestamp (Note 1) 

Other values are reserved for future use 



(octets) 
Bits 

8 765432 the first (right) 8 bits of the Timestamp 
1 



(octet 4) 

Bits 

8 7 6 5 4 3 2 the next 8 bits of the Timestamp 
1 



(octet 5) 

Bits 

8 7 6 5 4 3 2 the next 8 bits of the Timestamp 
1 



(octet 6) 

Bits 

8 765432 the next 8 bits of the Timestamp 
1 

Note 1 - Timestamp in 32 bits format. 



7.4.2.15 Refer-to 

The Refer-to information element included in the II Refer message identifies a third party that the recipient of the II 
Refer message should contact. The third party is identified either with an E. 164 number or a SIP URI and it is included 
in the Refer-to information element as shown in figure 7.4.2.15.1 and table 7.4.2.15.1. 

The Code specific field as specified in table 7.4.2.15.1, the bits 3, 2, and 1 of the octet number 1 specify the type of 
information that is used to identify the third party to be contacted. 

When the Code specific field (bits 3, 2, and 1 of the octet number 1) is set to "001", as shown in table 7.4.2.15.1, it 
indicates that the Refer-to information element contains an E.164 number, i.e. the third party is identified with an E. 164 
number. When the Refer-to information element contains an E.164 number, the E.164 digit-string is included in the 
octet 3, octet 4, octet 5, etc. as shown in table 7.4.2.15.1. 

Octet 

1 

2 
, 4 

Figure 7.4.2.15.1: Refer-to information element 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
110 1 


Code specific 


Information Element length (in octets) 


Information Element body 
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Table 7.4.2.15.1 : Refer-to information element 



(octet 1) 
Bits 
32 1 
000 
001 



Code specific 



Unspecified 

The third party to be contacted is identified with an E.164 number (Note 1) 

Other values are reserved for future use 



(octets) 
Bits 
8765 



the most significant digit of the E.164 digit-string 



(octet 3) 
Bits 
4321 



the next significant digit of the E.1 64 digit-string (Note 2) 



(octet 4) 
Bits 
8765 



the next significant digit of the E.1 64 digit-string (Note 2) 



the next significant digit of the E.1 64 digit-string (Note 2) 



(octet 4) 

Bits 

4321 
(next octet) 

Bits 

(Note 3) 
Note 1 - Prefix or escape digits shall not be included. 

Note 2 - The next significant digits of the E.1 64 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 
2. 

Note 3 -The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any 
octet indicating the end of the E.164 digit-string. 



7.4.2.16 



Conference-id 



The Conference-id information element is used by the SCC AS to convey to the ICS UE the identity of the conference 
focus (i.e. SIP URI or an E.164 number) that will handle the requested conference call. 

The Conference-id information element may contain either a SIP URI or an international telephone number (i.e. an 
E.164 national number). The Code specific field as specified in table 7.4.2.16.1, the bits 3, 2, and 1 of the octet 
number 1 specify the type of information that is used to identify the conference focus. 

When the Code specific field (bits 3, 2, and 1 of the octet number 1) is set to "001", as shown in table 7.4.2.16.1, it 
indicates that the Conference-id information element contains an E.164 number, i.e. the conference focus is identified 
with an E.164 number. When the Conference-id information element contains an E.164 number, the E.164 digit-string 
is included in the octet 3, octet 4, octet 5, etc. as shown in table 7.4.2.16.1. 

Octet 

1 

2 
4 

Figure 7.4.2.16.1: Conference-id information element 



8 


7 6 5 4 


3 2 1 


1 


Information Element code 
1110 


Code specific 


Information Element length (in octets) 


Information Element body 
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Table 7.4.2.16.1: Conference-id information element 



(octet 1) Code specific 

Bits 
321 



Unspecified 

1 Conference focus is identified with an E.164 number (Note 1) 

Other values are reserved for future use 



(octets) 
Bits 
8 7 6 5 the most significant digit of the E.164 digit-string 



(octet 3) 
Bits 
4 3 2 1 the next significant digit of the E.I 64 digit-string (Note 2) 



(octet 4) 
Bits 
8 7 6 5 the next significant digit of the E.1 64 digit-string (Note 2) 



(octet 4) 

Bits 

4 3 2 1 the next significant digit of the E.1 64 digit-string (Note 2) 

(next octet) 

Bits 

(Note 3) 
Note 1 - Prefix or escape digits shall not be included. 

Note 2 - The next significant digits of the E.1 64 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 
2. 

Note 3 -The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any 
octet indicating the end of the E.164 digit-string. 



7.5 Session states and Session control procedures 

7.5.1 General 

This clause defines the basic session control states that an individual session may acquire. Since several sessions may 
exist simultaneously across the II interface and each session may be in a different state, the session states describe the 
state of a particular session rather then describing the state of the II interface. The procedures for session control are 
given in subclause 7.5.3. 

7.5.2 Session states 

7.5.2.1 Session originated by the ICS UE 

7.5.2.1 .1 Session states at ICS UE - ICS UE originated call 

This subclause lists the session states that may exist at the UE for a session originated by the ICS UE. 

null: No II session exists. 

trying: This state exists for an UE originated session, when the ICS UE has requested a session establishment by 
sending an Illnvite message but has not yet received any response. 

proceeding: This state exists for an UE originated session when the ICS UE has received an II Progress 
message with Progress reason set to Call progressing from the SCC AS acknowledging that the SCC AS has 
received the II Invite message. 

alerted: This state exists for an UE originated session when the calling ICS UE has received an II Progress 
message with Progress reason set to Ringing indicating that remote endpoint alerting has been initiated. 

confirmed: This state exists for an UE originated session when the ICS UE has received an II Success message 
indicating that the remote endpoint has accepted the session. 
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7.5.2.1 .2 Session states at SCC AS - ICS UE originated call 

This subclause lists the II session states that may exist at the SCC AS for a II session originated by the ICS UE. 

null: No II session exists. 

initiated: This state exists for an UE originated II session when the SCC AS has received an II Invite message 
but has not yet responded. 

progressing: This state exists for an UE originated II session when the SCC AS has sent an II Progress message 
with Progress reason set to Call progressing acknowledging that the SCC AS has received the Illnvite message. 

alerting: This state exists for an UE originated II session when the SCC AS has sent an II Progress message 
with Progress reason set to Ringing indicating that remote endpoint alerting has been initiated. 

confirmed: This state exists for an UE originated II session when the SCC AS has sent an II Success message 
indicating that the II session has been accepted. 

7.5.2.2 Session terminated at the ICS UE 

7.5.2.2.1 Session states at UE - ICS UE terminated call 

This subclause lists the II session states that may exist in the UE for all session terminated at the ICS UE. 

null: No II session exists. 

initiated: This state exists for a II session terminated at the UE when the ICS UE has received an Illnvite 
message but has not yet responded. 

progressing: This state exists for all session terminated at the UE when the ICS UE has sent an II Progress 
message with Progress reason set to Call progressing acknowledging that the ICS UE has received the Illnvite 
message. 

alerting: This state exists for a II session terminated at the UE when the ICS UE has sent an II Progress 
message with Progress reason set to Ringing indicating that local alerting has been initiated but the offered call 
has not yet answered. 

confirmed: This state exists for all session terminated at the UE when the ICS UE has sent an II Success 
message indicating that the II session has been accepted. 

7.5.2.2.2 Session states at SCC AS - ICS UE terminated session 

This subclause lists the session states that may exist in the UE for a session terminated at the ICS UE. 

null: No II session exists. 

trying: This state exists for a session terminated at the ICS UE when the SCC AS has requested a session 
establishment by sending an II Invite message but has not yet received a response. 

proceeding: This state exists for a session terminated at the ICS UE when the SCC AS has received an II 
Progress message with Progress reason set to Call progressing from the UE acknowledging that the ICS UE has 
received the Illnvite message. 

alerted: This state exists for an UE terminated session when the SCC AS has received an II Progress message 
with Progress reason set to Ringing indicating that the UE has initiated local alerting. 

confirmed: This state exists for a session terminated at the UE when the SCC AS has received an II Success 
message indicating that the ICS UE has accepted the session. 
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7.5.2.3 Session release 

7.5.2.3.1 Session states at ICS UE 

This subclause lists the session states that may exist at the UE for a session released either by the ICS UE or SCC AS. 

release-requested: This state exists when the ICS UE has requested the SCC AS to clear the session by sending 
an II Bye message and the CS bearer has not been cleared using receipt of a DISCONNECT message, in 
accordance with 3GPP TS 24.008 [3]. Upon determining that the CS bearer has cleared using a DISCONNECT 
message or determining that an II Success message was received, the UE transits to a "null" state. The ICS UE 
attempts to clear the CS bearer if a retransmission timer fires. 

release-indication: This state exists when the ICS UE has received an II Bye message from the SCC AS 
requesting the UE to clear the session. Per subclause 6.2.3.1.2, upon subsequent clearing the CS bearer using a 
DISCONNECT message, in accordance with 3GPP TS 24.008 [3], or upon subsequent sending of an II Success 
message, the ICS UE transits to a "null" state. 

NOTE: The retransmission timer, which is not defined in this specification, is selected appropriately for the 
transport layer in use. 

7.5.2.3.2 Session states at SCC AS 

This subclause lists the session states that may exist at the SCC AS for a session released either by the ICS UE or SCC 
AS. 

release-requested: This state exists when the SCC AS has requested the ICS UE to clear the session by sending 
an II Bye message and the CS bearer has not been cleared. Upon determining that the CS bearer has cleared 
using a DISCONNECT message, in accordance with 3GPP TS 24.008 [3] and 3GPP TS 24.292 [5] or 
determining that a II Success message was received, the SCC AS transits to a "null" state. The SCC AS attempts 
to clear the CS bearer if a retransmission timer fires. 

release-indication: This state exists when the SCC AS has received an IlBye message from the ICS UE 
requesting the SCC AS to clear the session. Upon subsequent clearing the CS bearer using a SIP BYE request 
sent towards the MGCF or upon subsequent sending of an II Success message in accordance with 
3GPP TS 24.292 [5], the SCC AS transits to a "null" state. 

NOTE: The retransmission timer, which is not defined in this specification, is selected appropriately for the 
transport layer in use. 

7.5.3 Session control procedures 

7.5.3.1 General 

Before the II session establishment procedures are invoked, a transport-layer connection must be established between 
the ICS UE and the SCC AS. 

7.5.3.2 Session establishment 
7.5.3.2.1 UE-originating case 
7.5.3.2.1.1 Procedure at ICS UE 

7.5.3.2.1.1.1 Session request 

The ICS UE initiates II session establishment procedure by sending an II Invite message to the SCC AS across the II 
interface. The II Invite message shall contain the II information elements as specified in subclause 6.2.1.2.1. Following 
the transmission of the II Invite message the II session shall transit to the "trying" state. When the II session identified 
by the Call-Identifier field (see subclause 7.2.2.1.4) enters the "trying" state, the ICS UE sets timer F to fire in T3 
seconds and timer Fl to fire in T4 seconds. 
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If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, the ICS UE sets timer E to fire 
in Tl seconds. For reliable transport-layer connection timer E is not used. If timer E fires while the II session is still in 
the "trying" state, the original II Invite message (with the same Call-Identifier field and sequence number) is 
retransmitted and the timer E is reset to value of MIN(2*T1, T2). If the timer E fires again, the original II Invite 
message (with the same sequence number) is retransmitted again and the timer E is reset to a MIN (4*T1, T2). This 
process continues so that retransmissions occur with an exponentially increasing interval that caps at T2. 

NOTE 1: Since the values for the timers Tl, T2 and T3 depend on the technology that is used to implement the 

transport-layer connection (e.g. USSD), the values for the timers Tl, T2 and T3 will be specified for each 
technology. 

If timer F fires or timer Fl fires while the session is still in the "trying" state, or timer E has fired 5 times the sessioncall 
establishment has failed, and the ICS UE clears the II session, as described in subclause 6.2.3. In addition, if an 
unreliable transport-layer connection between the UE and the SCC AS is used, the ICS UE disables timer E. 

7.5.3.2.1 .1 .2 Session proceeding 

If an II Progress message with Progress reason set to Call progressing and containing an SCC AS PSI DN is received at 
the ICS UE while the II session identified by a valid Call-Identifier field (see subclause 7.2.2.1.4) is in the "trying" 
state, the II session shall transit to the "proceeding" state and timer Fl shall be stopped and cleared. If an an unreliable 
transport-layer connection between the ICS UE and the SCC AS is used timer E shall be stopped and cleared. 

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, when the session enters the 
"proceeding" state the ICS UE sets the timer E to fire in T2 seconds. If timer E fires while the session is in the 
"proceeding" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is 
reset to a value of T2 seconds. This process continues so that retransmissions of the original II Invite message occur 
every T2 seconds. 

If timer F fires while the session is in the "proceeding" state, or timer E has fired 5 times the session establishment has 
failed, and the ICS UE clears the call, as described in subclause 6.2.3. In addition, if an unreliable transport-layer 
connection between the ICS UE and the SCC AS is used, the ICS UE disables timer E. 

Upon receiving the II Progress message with Progress reason set to Call progressing from the SCC AS, the ICS UE 
initiates the setting up of the CS bearer connection toward the SCC AS by sending a SETUP message to the MSC 
Server as specified in subclause 6.2.1.2.1. 

NOTE: The request to set up the CS bearer connection arriving at the SCC AS indicates that the II Progress 
message with Progress reason set to Call progressing has been received by the UE. Subsequently, the 
SCC AS can progress the II session toward the far end by sending a SIP INVITE request to the far end. 

7.5.3.2.1.1.3 Alerting indication 

If an II Progress message with Progress reason set to Ringing is received while the II session identified by a valid Call- 
Identifier field (see subclause 7.2.2.1.4) is in the "proceeding" state, the II session shall transit to the "alerted" state. 

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, when the session enters the 
"alerted" state the ICS UE sets timer E to fire in T2 seconds. If timer E fires while the session is in the "alerted" state, 
the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 
seconds. This process continues so that retransmissions of the original II Invite request occur every T2 seconds. 

If timer F fires while the session is in the "alerted" state, or timer E has fired 5 times the session establishment has 
failed, and the ICS UE clears the call, as described in subclause 6.2.3. In addition, if an unreliable transport-layer 
connection between the ICS UE and the SCC AS is used, the ICS UE disables timer E. 

If the ICS UE receives an II Progress message with Progress reason set to Ringing, the ICS UE may begin a locally- 
generated alerting procedure. 

7.5.3.2.1 .1 .4 Session connected 

If an II Success message is received from the SCC AS while the II session at the UE is either in the "proceeding" state 
or "alerted" state, the II session shall transit to the "confirmed" state (i.e., the II session has been established) and the 
timer F is disabled. The ICS UE shall stop any locally generated alerting procedures (if applied). 
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If an unreliable transport-layer connection between the ICS UE and the SCC AS was used, the timer E is disabled, 
hence the ICS UE stops retransmitting the II Invite message. In addition, the ICS UE discards any subsequent II 
Success message, if it is received over the unreliable transport-layer connection. 

7.5.3.2.1 .2 Procedure at SCC AS 

7.5.3.2.1.2.1 Session request 

Upon receiving an II Invite message from the ICS UE over the II interface, the session at the SCC AS shall transit to 
the "initiated" state. Once in the "initiated" state, the SCC AS shall immediately respond by sending an II Progress 
message with Progress reason set to Call progressing to the UE and the session enters the "progressing" state. The II 
Progress message with Progress reason set to Call progressing shall contain the II information elements as specified in 
subclause 6.2.1.3.1. 

NOTE: The receipt of the II Progress message with Progress reason set to Call progressing at the UE, will trigger 
the UE to set up a CS bearer connection toward the SCC AS by sending a SETUP message to the MSC 
Server as specified in subclause 6.2.1.2.1. 

7.5.3.2.1.2.2 Session progressing 

If the SCC AS receives a retransmitted II Invite message from the ICS UE, while the II session identified by a valid 
Call-Identifier field (see subclause 7.2.2.1.4) is in the "progressing" state, the SCC AS shall retransmit the previously 
sent II Progress message with Progress reason set to Call progressing to the ICS UE. 

NOTE: The SCC AS receives a retransmitted II Invite message only if the transport-layer connection between the 
ICS UE and the SCC AS is an unreliable transport-layer connection. While the II session is in the 
"progressing" state, the SCC AS may send to the ICS UE either an II Progress message with Progress 
reason set to Ringing, an II Success message indicating that the II session has been accepted, or a new II 
Progress response with Progress reason set to Call progressing. 

If timer F fires while the session is in the "progressing" state, the II session establishment has failed, and the SCC AS 
clears the II session, as described in subclause 6.2.3. 

7.5.3.2.1.2.3 Alerting indication 

If the SCC AS sends an II Progress message with Progress reason set to Ringing to the ICS UE, the session state at the 
SCC AS shall transit to the "alerting" state. 

If the SCC AS receives a retransmitted II Invite message from the ICS UE identified by a valid Call-Identifier field (see 
subclause 7.2.2.1.4), while the session is in the "alerting" state, the SCC AS shall retransmit the previously sent II 
Progress message with Progress reason set to Ringing to the ICS UE. 

NOTE: The SCC AS receives a retransmitted II Invite message only if the transport-layer connection between the 
UE and the SCC AS is an unreliable transport-layer connection. 

If timer F fires while the session is in the "alerting" state, the session establishment has failed, and the SCC AS clears 
the session, as described in subclause 6.2.3. 

7.5.3.2.1.2.4 Session connected 

If the SCC AS sends an II Success message to the ICS UE indicating that the session has been accepted, the session 
state at the SCC AS shall transit to the "confirmed" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the 
"confirmed" state the SCC AS sets timer G to fire in (n*T2) seconds. For reliable transport-layer connection timer G is 
not used. If a retransmitted II Invite message is received while the timer G is running, the timer G is reset to fire in 
(n*T2) seconds, and the II Success message is retransmitted. The firing of the timer G indicates that the ICS UE has 
received the II Success message and the ICS UE has stopped the retransmission of the II Invite message. 

If timer G fires while the session is in the "confirmed" state, the timer F is disabled. 

If timer F fires while the session is in the "proceeding" state, or timer G has fired 5 times the session establishment has 
failed, and the SCC AS resets timer G and clears the session, as described in subclause 6.2.3. 
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7.5.3.2.2 UE-terminating case 

7.5.3.2.2.1 Procedure at I CS UE 

7.5.3.2.2.1.1 Session request 

Upon receiving an II Invite message from the SCC AS over the II interface, the session at the ICS UE shall transit to 
the "initiated" state. Once in the "initiated" state, the ICS UE shall immediately respond by sending an II Progress 
message with Progress reason set to Call progressing to the SCC AS and enter the "progressing" state. The II Progress 
message with Progress reason set to Call progressing shall contain the II information elements as specified in 

subclause 6.2.1.2.2. 

NOTE: The receipt of the II Invite message at the UE will trigger the UE to set up a CS bearer connection toward 
the SCC AS by sending a SETUP message to the MSC Server as specified in subclause 6.2.1.2.1. 

When the session enters the "initiated" state, the ICS UE also sets timer F to fire in T3 seconds. 

7.5.3.2.2.1.2 Session progressing 

If the ICS UE receives a retransmitted II Invite message from the SCC AS, while the II session is in the "progressing" 
state, the ICS UE shall retransmits the previously sent II Progress message with Progress reason set to Call progressing 
to the UE. 

NOTE: The UE receives a retransmitted II Invite message only if the transport-layer connection between the UE 
and the SCC AS is an unreliable transport-layer connection. 

While the session is in the "progressing" state, the ICS UE may send to the SCC AS with the same Call-Identifier field 
(see subclause 7.2.2.1.4), either an II Progress message with Progress reason set to Ringing, an II Success message 
indicating that the call has been accepted, or a new II Progress message with Progress reason set to Call progressing. 

If timer F fires while the session is in the "progressing" state, the session establishment has failed, and the ICS UE 
clears the call, as described in subclause 6.2.3. 

7.5.3.2.2.1.3 Alerting indication 

If the ICS UE sends an II Progress message with Progress reason set to Ringing, the session state at the ICS UE shall 
transit to the "alerting" state. 

If the ICS UE receives a retransmitted II Invite message from the SCC AS with the same Call-Identifier field (see 
subclause 7.2.2.1.4), while the session is in the "alerting" state, the ICS UE shall retransmit the previously sent II 
Progress message with Progress reason set to Ringing to the SCC AS. 

NOTE: The UE receive a retransmitted II Invite message only if the transport-layer connection between the UE 
and the SCC AS is an unreliable transport-layer connection. 

If timer F fires while the session is in the "alerting" state, the session establishment has failed, and the UE clears the 
session, as described in subclause 6.2.3. 

7.5.3.2.2.1.4 Session connected 

If the ICS UE sends an II Success message with a valid Call-Identifier field (see subclause 7.2.2.1.4) indicating that the 
session has been accepted, the session state at the UE transits to the "confirmed" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, the ICS UE sets timer G to fire in 
(n*T2) seconds. For reliable transport-layer connection timer G is not used. If an II Invite message is received while the 
timer G is running, the timer G is reset to (n*T2) seconds, and the II Success message is retransmitted. The firing of the 
timer G indicates that the SCC AS has received the Success message and has stopped the retransmission of the II Invite 

message. 

If timer G fires while the session is in the "confirmed" state or timer G has fired 5 times, the timer F is disabled. 

If timer F fires while the session is in the "confirmed" state, the session establishment has failed, and the ICS UE clears 
the session, as described in subclause 6.2.3. 
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7.5.3.2.2.2 Procedure at SCC AS 

7.5.3.2.2.2.1 Session request 

The SCC AS initiates a session establishment procedure by sending an II Invite message to the UE across the II 
interface. The II Invite message shall contain the II information elements as specified in subclause 6.2.1.3.2. Following 
the transmission of the II Invite message the session shall transit to the "trying" state. When the session enters the 
"trying" state, the SCC AS sets timer F to fire in T3 seconds timer Fl to fire in T4 seconds. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, the SCC AS sets timer E to fire in 
Tl seconds. For reliable transport-layer connection timer E is not used. If timer E fires while the session is still in the 
"trying" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset 
to value of MIN(2*T1, T2). If the timer E fires again, the original II Invite message (with the same Call-Identifier field 
and sequence number) is retransmitted again and the timer E is reset to a MIN (4*T1, T2). This process continues so 
that retransmissions occur with an exponentially increasing interval that caps at T2. 

If timer F fires or timer Fl fires while the session is still in the "trying" state or timer E has fired 5 times, the session 
establishment has failed, and the SCC AS clears the session, as described in subclause 6.2.3. In addition, if an unreliable 
transport-layer connection between the UE and the SCC AS is used, the SCC AS disables timer E. 

7.5.3.2.2.2.2 Call proceeding 

If an II Progress message with Progress reason set to Call progressing is received at the SCC AS while the session 
identified by a valid Call-Identifier field (see subclause 7.2.2.1.4) is in the "trying" state, the session shall transit to the 
"proceeding" state and timer Fl shall be stopped and cleared. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the 
"proceeding" state the SCC AS sets timer E to fire in T2 seconds. If timer E fires while the session is in the 
"proceeding" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is 
reset to a value of T2 seconds. This process continues so that retransmissions of the original II Invite message occur 
every T2 seconds. 

If timer F fires while the session is in the "proceeding" state or timer E has fired 5 times, the session establishment has 
failed, and the SCC AS clears the session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer 
connection between the UE and the SCC AS is used, the SCC AS disables timer E. 

NOTE: The request to set up the CS bearer connection arriving at the SCC AS indicates that the II Invite message 
has been received by the UE. 

7.5.3.2.2.2.3 Alerting indication 

If an II Progress message with Progress reason set to Ringing is received while the session identified by a valid Call- 
Identifier field (see subclause 7.2.2.1.4) is in the "proceeding" state, the session shall transit to the "alerted" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the 
"alerted" state the SCC AS sets timer E to fire in T2 seconds. If timer E fires while the session is in the "alerted" state, 
the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 
seconds. This process continues so that retransmissions of the original II Invite message occur every T2 seconds. 

If timer F fires while the session is in the "alerted" state or timer E has fired 5 times, the session establishment has 
failed, and the SCC AS clears the session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer 
connection between the UE and the SCC AS is used, the SCC AS disables timer E. 

7.5.3.2.2.2.4 Session connected 

If an II Success message is received from the ICS UE while the II session identified by a valid Call-Identifier field (see 
subclause 7.2.2.1.4) at the SCC AS is either in the "proceeding" state or "alerted" state, the II session shall transit to the 
"confirmed" state (i.e., the II session has been established) and the timer F is disabled. 

If an unreliable transport-layer connection between the UE and the SCC AS was used, the timer E is disabled, hence the 
SCC AS stops retransmitting the II Invite message. In addition, the SCC AS discards any subsequent II Success 
message, if it is received over the unreliable transport-layer connection. 
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7.5.3.3 11 service control signalling release 

7.5.3.3.1 Initiating release of II service control signalling 

The ICS UE or the SCC AS can release a II service control signalling session at any time irrespective of its state. The 
ICS UE or the SCC AS releases the II service control signalling session by sending an II Bye message across the II 
interface. The II Bye message shall contain the II information elements as specified in subclause 6.2.3. 

If an II Success message is received while the II service control signalling session is in the "release-requested" state, it 
transits to the "null" state (i.e., the II service control signalling session has been released). 

7.5.3.3.2 Responding to release of II service control signalling 

If either the ICS UE or the SCC AS receives an II Bye message across the II interface that contains a Call-Identifier 
field (see subclause 7.2.2.1.4) for a Call-Identifier field value identifying an II session that is any state other than null 
state, the state of the II service control signalling session at the recipient side of the II Bye message (i.e. either at the 
ICS UE or the SCC AS) shall transit to the "release-indication" state. If there are more II service control signalling 
sessions, once in the "release-indication" state, the recipient side of the II Bye message shall immediately respond by 
sending an II Success message. 

7.5.3.4 Receipt of a transport protocol error 
7.5.3.4.1 USSD Transport 

If the ICS UE or SCC AS receives "systemFailure" or "unexpectedDataValue" as specified in 3GPP TS 24.080 [24] 
then: 

a) the II session is cleared, as described in subclause 6.2.3; and 

b) II shall be disabled until: 

i) the UE changes PLMNs identified by MNC received in the Location area identification IE as specified in 
3GPP TS 24.008 subclause 10.5.1.3 in the Location updating accept message as defined in 3GPP TS 24.008 
subclause 9.2.13; or 

ii) the UE is turned off. 
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Annex A (normative): 

Data structure associating keys with values 

A.1 General 

A UE and a SCC AS maintain a hash table associating keys with values. The keys shall be hashes resulting of applying 
a hashing function to string values. SHA-1 shall be used as the hash algorithm. 

A.2 Associating keys with values 

The UE and the SCC AS shall have one or more tables associating keys with values. 

A.2.1 Associating keys with public user identities 

The UE and the SCC AS shall create a hash table of the SIP URIs present in the P-Associated-URI header field. If the 
UE and SCC AS also subscriber to the Reg-Event package as documented in 3GPP TS 24.229 [12] the UE and SCC AS 
shall create a hash table of the GRUU's for URIs received in the Reg-Event package in addition to those received in the 
P-Associated-URI header field. 

NOTE: The 200 (OK) response to a incoming REGISTER request includes a P-Associated-URI header field and 
is delivered to the SCC AS as part of the third party registration procedures documented in 

3GPPTS 24.229 [12]. 
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